| --- Log opened Wed May 14 00:00:12 2008 |
| 01:39 | | Mojo1978 [~Mojo1978@Nightstar-10455.dip.t-dialin.net] has joined #code |
| 01:41 | <@ToxicFrog> | Hmm. Ok, I think I've worked out how this will work. |
| 01:41 | <@ToxicFrog> | The semantics: |
| 01:42 | <@ToxicFrog> | - send accepts a target and a message. It blocks until the target has recieved the message. |
| 01:42 | <@ToxicFrog> | - receive accepts a mask. It blocks until a sender which is permitted by the mask attempts to send it a message, upon which it returns the message. |
| 01:43 | <@ToxicFrog> | - signal accepts a target and a primitive message. It returns immediately and the target receives the message on some future call to receive. |
| 01:43 | <@ToxicFrog> | - messages are received in the order that send/signal were called |
| 01:44 | <@ToxicFrog> | The implementation: |
| 01:45 | <@MyCatVerbs> | You maybe wanna add a tryReceive to that so people can poll without blocking? |
| 01:45 | <@ToxicFrog> | Probably. |
| 01:46 | <@MyCatVerbs> | Your "send" there sounds like Occam's message-passing and your "signal" like Erlang's. |
| 01:46 | <@MyCatVerbs> | I'd advise that everyone I've met who's ever used Occam hates it, but I haven't heard similar reactions to Erlang. |
| 01:47 | <@ToxicFrog> | I stole them both from Thoth, as it happens, although the semantics of send there are somewhat different. |
| 01:47 | <@ToxicFrog> | In that it blocks until the message is received and replied to, and returns the reply. |
| 01:47 | <@MyCatVerbs> | send seems incidental, given that it can be trivially implemented in terms of signal, is the only other issue. |
| 01:48 | <@ToxicFrog> | I have chosen to implement a more general form of send/receive, which Thoth send/receive as a sublibrary implemented in terms of it. |
| 01:49 | <@ToxicFrog> | Send is not incidental; it supports more data types than signal, because it can guarantee that the receiver is ready and copy the message directly into it. |
| 01:49 | <@ToxicFrog> | Signal can only transfer data types that can be easily extracted into C - numbers, booleans, strings, and pointers. |
| 01:51 | <@ToxicFrog> | Indeed, I don't actually like signal, as it can be easily implemented in terms of couriers. |
| 01:51 | <@ToxicFrog> | It'll probably stay in for performance reasons, though, since each courier is an additional thread and two message passes rather than one. |
| 01:52 | <@ToxicFrog> | (on the other hand, they don't have the same data type restrictions as signal, so some applications will need them) |
| 01:53 | <@ToxicFrog> | Any other issues? |
| 01:53 | | Mojo1978 [~Mojo1978@Nightstar-10455.dip.t-dialin.net] has quit [Ping Timeout] |
| 01:56 | <@ToxicFrog> | Alright then. |
| 01:56 | <@ToxicFrog> | Moving on to how this will actually be accomplished. |
| 01:56 | <@ToxicFrog> | Each thread maintains a list of threads which are currently send blocked on it. This list is protected by a mutex and a condition variable. |
| 01:57 | | Mojo1978 [~Mojo1978@Nightstar-9043.dip.t-dialin.net] has joined #code |
| 01:57 | <@McMartin> | Yay, backscroll! |
| 01:57 | | * McMartin goes to read |
| 01:57 | <@ToxicFrog> | When sending, a thread locks the mutex, appends itself to the list, unlocks the mutex, and waits on its personal "I am send blocked, please wake me up when ready" semaphore or perhaps barrier. |
| 01:58 | <@ToxicFrog> | Oh, and signals the condition variable. |
| 01:58 | <@McMartin> | Can't be a barrier. |
| 01:58 | <@ToxicFrog> | Why not? |
| 01:58 | <@McMartin> | Er, wait |
| 01:59 | <@McMartin> | OK, barriers aren't CVs |
| 01:59 | <@McMartin> | But I think you get CV problems. |
| 01:59 | <@McMartin> | Unlocks the mutex... gets the "OK, it's ready" signal and ignores it... waits forever |
| 01:59 | <@ToxicFrog> | Er? |
| 01:59 | <@McMartin> | Only semaphores can be pre-emptively unlocked. |
| 01:59 | <@ToxicFrog> | Yes, I know. |
| 01:59 | <@ToxicFrog> | Just hang on. |
| 01:59 | <@McMartin> | Which is what you need for this to work. |
| 01:59 | <@ToxicFrog> | Yes, I explain this in a moment. |
| 02:00 | <@McMartin> | OK |
| 02:00 | <@ToxicFrog> | When receiving, the thread grabs the mutex, and then walks the list looking for the first thread which is accepted by the mask. |
| 02:00 | <@ToxicFrog> | If it finds one, it releases the mutex, wakes up that thread, does all the bit shuffling required and returns. |
| 02:00 | <@ToxicFrog> | No, wait. |
| 02:00 | <@ToxicFrog> | It *removes that thread from the list*, releases the mutex, etc etc |
| 02:01 | <@ToxicFrog> | If it doesn't, it waits on the condition variable. |
| 02:01 | <@McMartin> | This is kind of an odd question |
| 02:01 | <@ToxicFrog> | Thus, whenever a new thread sends, it pings the CV to let the receiver know, if currently waiting, that a new thread has appeared and it can check to receive again. |
| 02:01 | <@McMartin> | ... hm |
| 02:01 | <@McMartin> | OK, I need to reupread on CVs. |
| 02:02 | <@ToxicFrog> | If the receiver isn't currently blocked on the CV, the signal is ignored, but that doesn't matter, because the first thing receive does is walk the list that's accumulated since last time. |
| 02:02 | <@McMartin> | I'm envisioning a bunch of CVs tied to the thread mutex, and wondering if that saves you any machinery |
| 02:02 | <@McMartin> | However, IIRC, CVs don't get to share mutexes |
| 02:02 | <@ToxicFrog> | No, just one CV. |
| 02:02 | <@ToxicFrog> | Each thread gets one list, one mutex, one CV, and that thread is the only thing that waits on the CV. |
| 02:03 | <@ToxicFrog> | Other threads signal the CV when they send() to it. |
| 02:03 | <@McMartin> | Didn't you just mention semaphores? |
| 02:03 | <@ToxicFrog> | That's inside the thread doing the send, not the receiver. |
| 02:03 | <@ToxicFrog> | So that the sender sleeps, and the receiver can then pick out a thread it wants to receive the message from and wake it up. |
| 02:04 | <@ToxicFrog> | (in practice, the receiver may actually do all the work, and use this only as a way to tell the sender "ok, I got the message, you can return now") |
| 02:05 | <@McMartin> | (I think you can probably fold that back into the mutex/CV pair, but this is my intuition talking.) |
| 02:05 | <@McMartin> | (Assuming you have the Proper CV semantics, which require a mutex to synchronize them) |
| 02:06 | <@ToxicFrog> | (I do. But I don't think I can, because (1) the receiver needs to wake up at a different time than the sender and (2) the semantics I need are "wake up this thread", not "any thread" or "all threads") |
| 02:07 | <@ToxicFrog> | (the receiver picks out one specific thread based on the order they showed up in and the receive mask, receives the message, and wakes up that thread to return from send) |
| 02:07 | <@McMartin> | (If each thread has its own CV, it's the only one that ever waits on it, you get that) |
| 02:07 | <@ToxicFrog> | Oh, right |
| 02:07 | <@ToxicFrog> | So the sender waits on its own cv, and the receiver pings it to wake it up |
| 02:08 | <@McMartin> | That will also let you automatically handle the keep-a-lock prelude in sender and postlude in receiver. |
| 02:08 | <@McMartin> | I think. |
| 02:08 | <@ToxicFrog> | This means I also need to wrap it in a "should we actually be awake" check, though, whereas a sem guarantees no spurious wakeups. |
| 02:08 | <@McMartin> | The sem fails to guarantee that you will actually go to sleep, though. |
| 02:08 | <@ToxicFrog> | Yeah, but that's not a problem. |
| 02:09 | <@McMartin> | OK. |
| 02:09 | <@McMartin> | I think for a proper review of it you want to draw a timing diagram for the protocol. |
| 02:09 | <@ToxicFrog> | If the sem is already posted when the sender waits on it, this just means that the sender was preempted and the receiver copied the message in between the sender releasing the receiver's mutex and waiting on its own sem. |
| 02:09 | <@McMartin> | Got it. |
| 02:09 | <@ToxicFrog> | In which case the sender has nothing more to do and should continue execution. |
| 02:13 | <@ToxicFrog> | So. Quick review: |
| 02:13 | <@ToxicFrog> | sender: lock r.mux; append self to r.list; signal r.cv; release r.mux; wait s.sem; return |
| 02:15 | <@McMartin> | r.cv and r.mux are linked, right? |
| 02:15 | <@ToxicFrog> | receiver: lock r.mux; walk list (remove s from list, release mux, copy data, post s.sem, return); wait r.cv; repeat; |
| 02:15 | <@ToxicFrog> | Yes. |
| 02:16 | <@McMartin> | OK, there's a gap here. |
| 02:17 | <@McMartin> | wait requires r.mux to be locked, and relocks it upon getting signalled. |
| 02:17 | <@McMartin> | You need to decide if r.mux can be unlocked between iterations. |
| 02:17 | <@McMartin> | It either needs to be unlock r.cv; repeat; |
| 02:17 | <@McMartin> | Or the lock r.mux needs to happen in r's constructor. |
| 02:19 | <@ToxicFrog> | It *has* to be unlocked between iterations, or senders can't update the list. |
| 02:19 | <@ToxicFrog> | And pthread_cond_wait unlocks it. |
| 02:19 | <@ToxicFrog> | I don't see what you're getting at. |
| 02:20 | <@McMartin> | During the wait, the lock is not held. |
| 02:20 | <@McMartin> | That's just part of the semantics of wait. |
| 02:20 | <@McMartin> | The question is whether it *also* unlocks between iterations. |
| 02:20 | <@McMartin> | And if it does, you need a timing diagram to ensure that there aren't ways senders can make things inconsistent. |
| 02:21 | <@McMartin> | If it doesn't, you may need to worry about excessive contention; not sure. |
| 02:22 | <@ToxicFrog> | Aah. |
| 02:22 | <@ToxicFrog> | It doesn't unlock between iterations, it relies on the wait. |
| 02:22 | <@ToxicFrog> | It holds the lock while examining the list, and if it needs to block, it simultaneously releases the lock and goes to sleep until it's updated. |
| 02:23 | <@McMartin> | Right |
| 02:23 | <@McMartin> | OK, so, the "lock r.mux" is outside of the repeat. |
| 02:23 | <@ToxicFrog> | Oh. |
| 02:23 | <@ToxicFrog> | Yes. |
| 02:23 | <@McMartin> | I see no problems with this then off hand. |
| 02:23 | <@ToxicFrog> | The one potential problem I can see is if the receiver assumes that only one thread has been added since it went to sleep, but as long as it doesn't assume that it should be fine, I believe. |
| 02:24 | <@ToxicFrog> | And it's easy enough to ensure that this is the case. |
| 02:24 | <@McMartin> | Just iterate through the whole list, right? |
| 02:24 | <@McMartin> | Oh, wait |
| 02:24 | <@McMartin> | What happens if you send to a thread that has you masked out? |
| 02:24 | <@McMartin> | That looks like it deadlocks the sender. |
| 02:24 | <@ToxicFrog> | The mask is per-call. |
| 02:25 | <@ToxicFrog> | per-call to receive, that is. |
| 02:25 | <@ToxicFrog> | So you block until the receiver calls with a mask that permits you. |
| 02:25 | <@ToxicFrog> | (and if the receiver never does so, yes, you block forever) |
| 02:25 | <@ToxicFrog> | (so don't do that) |
| 02:25 | <@McMartin> | Got it |
| 02:27 | <@ToxicFrog> | TBH, the only use I have for the mask at present is to make it possible to implement reply as well, but it's a general mechanism that other people will hopefully find more useful. |
| 02:27 | <@McMartin> | The deadlock possibility worries me, and you might want some kind of default timeout mechanism or something, but... |
| 02:28 | <@ToxicFrog> | Timeouts are work >.> |
| 02:29 | <@McMartin> | True enough~ |
| 02:29 | <@McMartin> | Though probably not much, and you can probably wrap the core to implement them. |
| 02:30 | <@ToxicFrog> | Yeah. |
| 02:30 | <@McMartin> | Any message you haven't received in over five seconds, say, you ping them for spite. |
| 02:33 | | Shoukanjuu [~Shoukanju@Nightstar-19663.dhcp.embarqhsd.net] has quit [Quit: Life is a game.. The object is to survive, to imprint in hostiry your legacy. Go forth and show them what you are, and why you, your memory, and your soul will not be so easily vanquished!] |
| 04:37 | <@ToxicFrog> | So, let's see. A thread needs: a lua_State, a pthread_cond_t, a pthread_mutex_t, a sem_t, a linked list of send blocked processes...am I missing anything? |
| 04:38 | <@ToxicFrog> | The thread * itself can function as the thread ID, so we don't need a seperate ID. |
| 05:26 | | Vornicus is now known as Vornicus-Latens |
| 05:41 | <@McMartin> | Are you entirely wedded to pthreads here? |
| 05:41 | <@McMartin> | You may get better cross-platformality via SDL's thread library. |
| 05:46 | <@ToxicFrog> | First cut will use pthreads. SDL will come later, if necessary. |
| 05:46 | <@ToxicFrog> | I'd rather not drag in all of SDL if I can avoid it, though. |
| 05:46 | <@McMartin> | Yeah |
| 05:47 | <@McMartin> | The Lua side doesn't care anyway |
| 05:47 | <@ToxicFrog> | Be nice if SDL_Threads were released as a small, stand alone, cross platform threading library. |
| 05:47 | <@McMartin> | That's probably doable given the source, but. |
| 05:49 | <@ToxicFrog> | Probably what I'll end up doing is releasing the posix/pthreads version, and then later, if I can't find a good pthreads wrapper for windows, releasing the windows build using SDL instead. |
| 05:49 | <@ToxicFrog> | Since it's socially acceptable to bundle support library DSOs on that platform~ |
| 05:49 | <@McMartin> | DSO? |
| 05:50 | <@McMartin> | Dynamic System Object? |
| 05:50 | <@McMartin> | Shared. |
| 05:53 | <@ToxicFrog> | Yeah. |
| 05:53 | <@ToxicFrog> | Anyways. Now, I sleep, for I have work in seven hours. 'night. |
| 05:54 | | Thaqui [~Thaqui@Nightstar-711.jetstream.xtra.co.nz] has joined #code |
| 05:54 | | mode/#code [+o Thaqui] by ChanServ |
| 06:30 | | AFKSkull [~none@Nightstar-7066.dyn.optonline.net] has quit [Ping Timeout] |
| 06:33 | | AnnoDomini [AnnoDomini@Nightstar-29567.neoplus.adsl.tpnet.pl] has joined #Code |
| 06:33 | | mode/#code [+o AnnoDomini] by ChanServ |
| 07:00 | | AFKSkull [~none@Nightstar-7066.dyn.optonline.net] has joined #code |
| 07:18 | | * Vornicus-Latens ARGHS as he finds himself writing a Dragon Dice roller thingy. |
| 07:18 | < Vornicus-Latens> | BAD VORNY, NO BISCUIT, WRITE CODE YOU'LL FINISH |
| 07:20 | | * AnnoDomini reasks his question, on the off-chance that it went unnoticed due timezone differences earlier. |
| 07:20 | <@AnnoDomini> | I have a networking question. I need to design a network where computers would be able to see each other, but wouldn't be able to see the routers themselves - packets originating from computers destined for the routers themselves should be dropped, or something, as long as they do not allow the computers knowledge of the router's mere existence. How do I do this? We're working on CISCO routers, an |
| 07:20 | <@AnnoDomini> | d the doc mentioned that we should use access lists. We're working on RIP, BTW, if it's important. |
| 07:22 | | * AnnoDomini needs to flee now, though. |
| 07:23 | <@GeekSoldier> | Did you say Dragon Dice? holy crap... I haven't played that in YEARS. |
| 07:25 | | * Vornicus-Latens founds some things that fell out of his dice bag, including a large dwarf archer and a small lava elf light infantry. |
| 07:35 | < Vornicus-Latens> | but man dragon dice is complicated. Though I guess if it weren't there'd be not much to the whole collectible bit |
| 07:45 | < AFKSkull> | vorn! tell me about node based bathfinding |
| 07:45 | < AFKSkull> | *path |
| 07:59 | <@Reiver> | What is Dragon Dice? |
| 08:01 | < AFKSkull> | it's a ccollectable card game except with collectable dice |
| 08:02 | <@Reiver> | ... |
| 08:17 | < AFKSkull> | and then you use the dice during play to provide a random element to combat. |
| 08:28 | <@Reiver> | This is a fairly standard use of dice, yes |
| 08:28 | <@Reiver> | I assume these dice are not merely labeled 1-6 or whatever, then? |
| 08:28 | < AFKSkull> | wouldn't be vry collectable, would they? |
| 08:29 | <@Reiver> | Precisely why I was wonderin'. |
| 08:29 | < AFKSkull> | I never played myself, so I can't help with details. |
| 08:35 | <@Reiver> | ...it looks really quite interesting, actually. |
| 08:50 | <@Kazriko> | I played it once. it was a bit complex. |
| 09:01 | | gnolam [lenin@Nightstar-10613.8.5.253.static.se.wasadata.net] has joined #Code |
| 09:01 | | mode/#code [+o gnolam] by ChanServ |
| 09:16 | | JeffL [JPL@Nightstar-12594.dsl.sndg02.pacbell.net] has quit [Connection reset by peer] |
| 09:45 | | AFKSkull [~none@Nightstar-7066.dyn.optonline.net] has quit [Ping Timeout] |
| 09:47 | | AFKSkull [~none@Nightstar-7066.dyn.optonline.net] has joined #code |
| 10:27 | | AFKSkull [~none@Nightstar-7066.dyn.optonline.net] has quit [Ping Timeout] |
| 10:33 | | AFKSkull [~none@Nightstar-7066.dyn.optonline.net] has joined #code |
| 12:51 | | Thaqui [~Thaqui@Nightstar-711.jetstream.xtra.co.nz] has left #code [Leaving] |
| 13:18 | | GeekSoldier [~Rob@Nightstar-9428.dip.t-dialin.net] has quit [Ping Timeout] |
| 14:53 | <@ToxicFrog> | Design change! |
| 14:53 | <@ToxicFrog> | We now have reply. |
| 14:53 | <@ToxicFrog> | Changed semantics: send blocks until the message is received and replied to, and returns the reply; reply can only be legally called on threads which are reply blocked on the caller. |
| 14:54 | <@ToxicFrog> | Changed design: the thread now has a second list (of reply-blocked threads). Before receiving, it moves the sender into this list. |
| 14:54 | <@ToxicFrog> | It does not post the sender's sem yet. |
| 14:55 | <@ToxicFrog> | When replying, it walks this list to see if the thread it's been passed is reply blocked. |
| 14:55 | <@ToxicFrog> | If not, it errors. If so, it copies the reply into the target's stack and posts the sem to wake it up, then returns. |
| 14:55 | <@ToxicFrog> | No locking is needed on this second list because reply is nonblocking, and the owner thread is the only thread that will be touching it. |
| 16:31 | <@AnnoDomini> | Hrm. How easy is it to produce an XML-supported HTML site that has login features, using Javascript? I've little to no experience with Javascript. Is it about as easy as using ASP? I don't care about hack-proofness here, since in all likelyhood, it won't be graded. |
| 16:45 | <@ToxicFrog> | They're kind of different things - ASP executes on the server, JS on the client |
| 16:45 | <@ToxicFrog> | If you really don't care *at all* about security you can do login validation on the client in JS quite easily, but that means finding out the credentials is a matter of hitting "view source" |
| 16:46 | <@AnnoDomini> | I store people's login information in an XML file, so I'll need to use that. |
| 16:50 | <@ToxicFrog> | Ok, so the idea is something AJAXy, where they enter the information, it downloads the XML file and validates the login based on the contents? |
| 16:50 | <@AnnoDomini> | Uhuh |
| 16:51 | <@AnnoDomini> | I have an example script that loads XML and XSL and outputs the results to a <div></div>. |
| 16:52 | <@AnnoDomini> | I'm mostly concerned with checking whether the bloke is still logged in. |
| 16:52 | <@AnnoDomini> | ASP had these session variables. |
| 16:53 | <@ToxicFrog> | That you'll have to handle server side, I think. |
| 16:53 | <@ToxicFrog> | Unless you can talk to the cookie store with JS or something. |
| 16:57 | <@AnnoDomini> | Uhuh. Sounds complicated. |
| 16:59 | <@AnnoDomini> | Or perhaps throw the 'loggedin="yes"' around the pages somehow. That would probably need every link to append an option like this. |
| 17:01 | <@AnnoDomini> | And maybe the username that is to be logged in. |
| 17:02 | <@AnnoDomini> | I'm pretty sure the security of that would be less than zero, but it's not a priority. Passing the damned class is a priority.- |
| 17:02 | <@AnnoDomini> | -- |
| 17:04 | | You're now known as TheWatcher[afk] |
| 17:48 | | Mojo1978 [~Mojo1978@Nightstar-9043.dip.t-dialin.net] has quit [Connection reset by peer] |
| 18:13 | | AnnoDomini is now known as Pete |
| 18:30 | | You're now known as TheWatcher |
| 18:50 | | Vornicus-Latens is now known as Vornicus |
| 18:53 | | ToxicFrog [~ToxicFrog@Admin.Nightstar.Net] has quit [Client exited] |
| 18:57 | | ToxicFrog [~ToxicFrog@Admin.Nightstar.Net] has joined #code |
| 18:57 | | mode/#code [+o ToxicFrog] by ChanServ |
| 19:10 | | GeekSoldier [~Rob@Nightstar-8409.dip.t-dialin.net] has joined #code |
| 19:10 | | mode/#code [+o GeekSoldier] by ChanServ |
| 19:38 | | Serah [~Z@87.72.35.ns-26506] has joined #Code |
| 19:38 | | mode/#code [+o Serah] by ChanServ |
| 20:14 | <@Pete> | Hm. Could anyone explain to me how to go between Cylinders/Sectors/Heads and logical addresses? It's going to be on a test next week, and I've not much a clue how that works. |
| 20:18 | | * Vornicus was not awarethat any HDs told the truth about that any more. |
| 20:18 | <@Pete> | HDs? We're working on floppies. |
| 20:19 | < Vornicus> | ah |
| 20:19 | < Vornicus> | i don't know anything about that, anyway. Just that a lot of HDs lie. |
| 20:19 | <@jerith> | There's usually an arbitrary mapping. |
| 20:20 | <@jerith> | Nothing above the OS level should ever care. |
| 20:20 | <@Pete> | Well, we've used Diskedit last time to edit the disk directly. |
| 20:21 | <@Pete> | And we implemented non-euclidean directories. |
| 20:22 | | * Vornicus gives Pete an iso which will make any computer go insane and play the Ring movie. |
| 20:22 | | * jerith drinks more wine. |
| 20:22 | <@Pete> | (Directories A and B in the root directory. Directory C in directory A. Files d.txt and e.txt inside directory C. Directories A and B inside directory C. Directory A inside directory B.) |
| 20:24 | <@Pete> | So... nobody have an idea how to translate CHS into logical and back? |
| 20:25 | < Vornicus> | Nope. |
| 20:29 | <@ToxicFrog> | Hang on |
| 20:30 | <@ToxicFrog> | Assuming the drive isn't doing something weird (like mapping the lowest logical addresses to the highest head number or somesuch, it should be something like: |
| 20:32 | <@ToxicFrog> | ((H * cylinders per head + C) * sectors per cylinder + S) * blocks per sector == LBA |
| 20:37 | <@Pete> | Uhuh. |
| 20:43 | <@ToxicFrog> | Unless C is more significant than H? |
| 20:43 | <@ToxicFrog> | It's been a long time since I had to deal with this. |
| 20:44 | <@Pete> | I'm not sure. |
| 20:47 | <@ToxicFrog> | Anyways. I just realized that by "explain" - did you want the forumula, or the conceptual overview? |
| 20:48 | <@Pete> | Both would suit. I like to understand things. |
| 20:51 | <@ToxicFrog> | Ok. First of all, how much do you know of the actual meaning of the terms cylinder, head, and sector, in this context? |
| 20:52 | <@Pete> | Let's see what I can remember. Cylinder is, well, a cylinder going through all the dishes. A head is... one side of a dish? A sector is... I don't know. |
| 20:52 | <@ToxicFrog> | platters, not dishes. |
| 20:52 | <@ToxicFrog> | And, ok. |
| 20:53 | <@ToxicFrog> | A head is one read/write head, used for actually modifying the contents of the disk. Modern drives almost invariably have two heads per platter, one on each side, as do floppies. |
| 20:54 | <@ToxicFrog> | Each platter is divided into concentric rings. A cylinder is the set of all rings at a certain radius - as if you took a hollow cylinder and dropped it through the platters. The rings that cylinder covers together make up a cylinder |
| 20:55 | <@ToxicFrog> | In effect, the cylinder is how far out from the center, and the head is how far up from the bottom, in the stack of platters. |
| 20:55 | <@ToxicFrog> | Together, these tell you which ring to look in. |
| 20:55 | <@ToxicFrog> | The ring itself is divided into sectors, which is where the sector number comes in. |
| 20:56 | | Serah [~Z@87.72.35.ns-26506] has quit [Quit: Don't try to read the quit message, that is impossible. Instead only realize the truth; "there is no quit message" and you will see it is not you who read the quit message but the quit message who reads you.] |
| 20:56 | <@ToxicFrog> | Each sector is the same size - 512 bytes is common - and is often the smallest size the drive can read in a single operation. |
| 20:57 | <@ToxicFrog> | So, CHS taken together tell you how far out, how far up, and how far around, which gives you a specific location on one surface of one platter of the drive. |
| 20:58 | <@Pete> | Cool. |
| 20:58 | | Pete is now known as AnnoDomini |
| 20:59 | <@ToxicFrog> | Now, it's important to note that the CHS numbers may bear no resemblance whatsoever to the actual layout of the drives. |
| 20:59 | <@ToxicFrog> | It's common to see, for example, drives which claim to have 1024 cyls and 65,535 heads. |
| 21:00 | <@ToxicFrog> | This is because old BIOSes which used CHS didn't support more than 1024 cyls, but could handle up to 2^16-1 heads, because someone, probably at IBM, was insane. |
| 21:00 | <@ToxicFrog> | So the drive reports fake numbers the BIOS can handle and internally uses the real ones. |
| 21:00 | <@ToxicFrog> | In practice, however, everything uses LBA these days. |
| 21:00 | <@ToxicFrog> | Well, HDDs do. |
| 21:00 | <@ToxicFrog> | Floppies might still use CHS, it's not something I've payed attention to. |
| 21:01 | <@ToxicFrog> | Anyways, the mapping between CHS and LBA. |
| 21:01 | <@ToxicFrog> | The idea of LBA is that the disk is treated as a contiguous array of blocks - you just ask for "block N" and the disk gives it to you, without needing to know where on disk it's actually stored. |
| 21:04 | <@ToxicFrog> | Let's say, for example, that you have a disk with 512-byte sectors; 8 sectors per track; 2 heads; and 16 cyls |
| 21:04 | <@ToxicFrog> | And let's say LBA blocks are also 512 bytes, to keep things simple. |
| 21:04 | <@ToxicFrog> | You ask for LBA block 0, and that's easy: CHS 0/0/0 |
| 21:04 | <@ToxicFrog> | LBA 1 is the next sector over - CHS 0/0/1 |
| 21:05 | | * AnnoDomini nods. |
| 21:05 | <@ToxicFrog> | Up to LBA 7, which is the last sector in that track. |
| 21:05 | <@ToxicFrog> | For LBA 8, you either move to the next head or the next cyl - let's say head, since that allows some cool optimizations and head is traditionally less significant than cyl anyways. |
| 21:05 | <@ToxicFrog> | So LBA 8 is CHS 0/1/0 |
| 21:06 | <@ToxicFrog> | By LBA 15, we've used up all the sectors in both heads of cyl 0, so we move out to the next cyl |
| 21:06 | <@ToxicFrog> | And LBA 16 is 1/0/0 |
| 21:07 | <@ToxicFrog> | The last sector on the disk - LBA 255 - is the last sector on the highest head of the outermost cyl, 15/1/7 |
| 21:08 | <@ToxicFrog> | Make sense? |
| 21:09 | <@AnnoDomini> | Yes... what LBA block sizes are common then? Or, at least, on a floppy? |
| 21:10 | | * AnnoDomini checks his half-intelligible notes. |
| 21:11 | <@AnnoDomini> | Wait, it says here sectors are 1-indexed. |
| 21:11 | <@ToxicFrog> | Go with that, then |
| 21:11 | <@ToxicFrog> | I tend to assume 0-indexing |
| 21:11 | <@AnnoDomini> | Okay. |
| 21:11 | <@ToxicFrog> | So all my examples are 0-indexed |
| 21:12 | <@AnnoDomini> | Thanks loads, man. |
| 21:12 | <@ToxicFrog> | As for block sizes on floppies...no idea. |
| 21:12 | <@ToxicFrog> | Like I said, I don't even know if floppies use LBA, they might still use CHS |
| 21:12 | <@AnnoDomini> | I'll just demand information from the doc. |
| 21:12 | <@ToxicFrog> | And even if the *interface* is LBA, the drive controller still needs to know how to translate to CHS to find the actual data on disk, which is why knowing how to do this is still relevant in this day and age. |
| 21:14 | <@AnnoDomini> | If sectors are 1-indexed, what would be the formula? |
| 21:15 | <@ToxicFrog> | for CHS to LBA? Assuming the others are 0-indexed, it's ((C * (heads per cyl) + H) * (sectors per head) + S-1) * (blocks per sect) |
| 21:16 | <@ToxicFrog> | Or, equivalently, C * (blocks per cyl) + H * (blocks per head) + (S-1) * (blocks per sect) |
| 21:16 | <@ToxicFrog> | It's just simple counting where each digit is in a different base. |
| 21:17 | <@AnnoDomini> | Okay. How about the reverse? |
| 21:17 | < Vornicus> | ...oh, that's why 0-indexing is preferred. You can have a multipart thing like this, and zero-indexing makes it so the entire split process is one operation (a shift) instead of multiple (a shift and an add) |
| 21:17 | <@ToxicFrog> | Vornicus: yep. |
| 21:17 | <@AnnoDomini> | Seems to me there could be a number of solutions, so we have to check for validity of CHS ranges. |
| 21:18 | <@ToxicFrog> | How can there be a number of solutions? |
| 21:18 | <@ToxicFrog> | If you know the numbers of cyls, sectors and heads in the target disk, there's only one possible solution |
| 21:18 | <@AnnoDomini> | One equation and three unknowns. |
| 21:18 | <@gnolam> | AnnoDomini: parameters of various floppy formats: http://www.apple2.org.za/mirrors/ground.icaen.uiowa.edu/MiscInfo/Misc/diskfmts . |
| 21:19 | <@ToxicFrog> | Three equations, three unknowns. |
| 21:19 | <@ToxicFrog> | C = floor(block/blocks_per_cyl) |
| 21:19 | <@ToxicFrog> | H = floor((block % blocks_per_cyl)/blocks_per_head) |
| 21:19 | <@gnolam> | (The "regular" PC floppy is the one marked (6) in that list) |
| 21:20 | <@ToxicFrog> | S = floor((block % blocks_per_head)/blocks_per_sect) |
| 21:20 | <@AnnoDomini> | Thanks. |
| 21:21 | <@ToxicFrog> | And you can determine all the blocks_per_foo just by knowing the CHS counts for the disk and by knowing blocks_per_sect |
| 21:22 | <@ToxicFrog> | (which in turn is just sectsize/blocksize) |
| 21:22 | <@ToxicFrog> | It's fundamentally the same process you perform to convert from, say, seconds to days/hours/minutes and back again. |
| 21:22 | <@ToxicFrog> | No ambiguity. |
| 21:23 | <@AnnoDomini> | Uhuh. |
| 22:20 | | Serah [~Z@Nightstar-5401.atm2-0-1041217.0xc329e232.boanxx12.customer.tele.dk] has joined #Code |
| 22:20 | | mode/#code [+o Serah] by ChanServ |
| 22:27 | | Serah is now known as Serah^WR0K |
| 22:38 | | * ToxicFrog mutters unflattering things about ubuntu as he goes through his known_hosts |
| 22:42 | | * Serah^WR0K PatPats ToxicFrog. |
| 22:43 | | * gnolam probably agrees with ToxicFrog's muttering. |
| 22:44 | <@ToxicFrog> | Well, in fairness - by which I mean, to broaden the set of targets - it's Debian's fault, not just Ubuntu's |
| 22:44 | <@ToxicFrog> | But most of the systems I interact with which are affected by this problem run Ubuntu, not Debian. |
| 22:46 | <@gnolam> | On the topic of Debian (and its derivatives), the recent OpenSSL bug was... interesting. |
| 22:47 | | gnolam [lenin@Nightstar-10613.8.5.253.static.se.wasadata.net] has quit [Quit: Reboot] |
| 22:52 | <@ToxicFrog> | Yes. |
| 22:53 | < Vornicus> | Yes, let's change the RNG of a crypto system /without consulting the guys who wrote it/ to /shut up a stupid warning/. |
| 22:53 | < Vornicus> | Moron. |
| 22:53 | <@ToxicFrog> | It's even better than that. |
| 22:53 | <@ToxicFrog> | they did consult. |
| 22:54 | < Vornicus> | Oh? |
| 22:55 | <@ToxicFrog> | And the openSSL guys said "this is desired behaviour, we like uninitialized variables, as mentioned on this list THOUSANDS OF TIMES FOR THE LOVE OF GOD DON'T YOU KNOW HOW TO USE THE SEARCH FEATURE, and if you're looking for actual problems compile with -DPURIFY, which will hide stuff like this that freaks out Valgrind and Purify, and try again" |
| 22:56 | < Vornicus> | pff |
| 22:56 | <@ToxicFrog> | In fairness to the debian guys, they didn't say "this is vital to the proper functioning of the RNG", but they did say "it is desired behaviour and should be left in unless you're building specifically for Valgrind testing" |
| 22:58 | <@ToxicFrog> | "No, it's fine - the problem is Purify and Valgrind assume all use of |
| 22:58 | <@ToxicFrog> | uninitialised data is inherently bad, whereas a PRNG implementation has |
| 22:58 | <@ToxicFrog> | nothing but positive (or more correctly, non-negative) things to say |
| 22:58 | <@ToxicFrog> | about the idea. |
| 22:58 | <@ToxicFrog> | Why do you think the "#ifndef PURIFY" logic is there? |
| 22:58 | <@ToxicFrog> | If you're going to run an openssl-based app under instrumentation and |
| 22:58 | <@ToxicFrog> | *look* for uses of uninitialised data, add "-DPURIFY" to your configure |
| 22:58 | <@ToxicFrog> | line. Please also search the archives for words like "Valgrind", |
| 22:58 | <@ToxicFrog> | "Purify", "uninitialised memory", etc. This has come up many times |
| 22:58 | <@ToxicFrog> | before." |
| 22:58 | <@ToxicFrog> | And now I have to check all my systems for bad keys generated on debian-derived systems. |
| 22:59 | <@McMartin> | What's the command to regenerate the system's keys? They're only talking per-user on the Debian site. |
| 23:01 | <@ToxicFrog> | I don't recall. |
| 23:09 | <@MyCatVerbs> | ToxicFrog: only DSA host keys and keys generated on Debian or Ubuntu boxes need regenerating, IIRC. |
| 23:10 | <@MyCatVerbs> | No need to panic over RSA keys migrated through Debian boxes, etc. Which helps. |
| 23:12 | <@MyCatVerbs> | Still. Seems crazy that they'd've put in all the silly memset calls at any point other than allocation. |
| 23:17 | | AnnoDomini [AnnoDomini@Nightstar-29567.neoplus.adsl.tpnet.pl] has quit [Quit: I am Yulaw! I am nobody's bitch! You - are mine.] |
| 23:19 | | gnolam [lenin@Nightstar-10613.8.5.253.static.se.wasadata.net] has joined #Code |
| 23:19 | | mode/#code [+o gnolam] by ChanServ |
| 23:33 | | gnolam [lenin@Nightstar-10613.8.5.253.static.se.wasadata.net] has quit [Quit: Z?] |
| 23:40 | | * McMartin stabs either Debian or Ubuntu in the face. |
| 23:41 | <@McMartin> | Thanks ever so much for making the SSH key regeneration interactive so that I had to rewire my monitor to perform the frickin' upgrade, guys |
| 23:48 | | McMartin [~mcmartin@Nightstar-7072.dsl.pltn13.sbcglobal.net] has quit [Quit: Reboot] |
| 23:52 | | McMartin [~mcmartin@Nightstar-7072.dsl.pltn13.sbcglobal.net] has joined #code |
| 23:52 | | mode/#code [+o McMartin] by ChanServ |
| 23:53 | <@MyCatVerbs> | Almost certainly Ubuntu. That really isn't Debian's style. |
| 23:54 | <@McMartin> | What, the interactive screen on update? |
| 23:55 | <@MyCatVerbs> | Mmmhmm. I honestly couldn't see Debian doing anything that required more interactivity than ncurses. |
| 23:56 | <@McMartin> | This was ncurses. |
| 23:57 | <@McMartin> | However, it shut down my ssh connection and then started doing ncurses things. |
| 23:57 | <@McMartin> | WRONG ORDER |
| 23:57 | <@McMartin> | To quote Skin Horse |
| 23:58 | <@McMartin> | WHAT DOES IT FEEL LIKE WHEN I REPEATEDLY STAB YOU? |
| --- Log closed Thu May 15 00:00:19 2008 |