On 10/9/06, David Brownell <[EMAIL PROTECTED]> wrote: > On Monday 09 October 2006 9:37 am, Christopher "Monty" Montgomery wrote: > > > > I hand you a pointer to memory and ask you what type it is. You can't > > tell me. > > A C "struct foo *" points to a "foo". > For a C "void *", the type info is out-of-band.
Right. You can't tell me because you don't have the out of band information. You have to also be given a way to get the oob type. > Now, the notion of hardware "typed pointers" has been around since the 1950s, > as I recall. General purpose computers don't implement them in hardware the > way that e.g. LISP machines did, but they do sometimes use the low order > bits of an address to encode type information ... just like EHCI hardware. > C doesn't have hardware pointer typing. Sure. And generally anything goes in systems programming. However... I resubmit the claim that eliminating needless complexity is good. There are many places in the EHCI driver where the hardware typed pointers are inescapable. That's not a reason [by itself] to use them for everything. > So? The out-of-band info has to be managed somehow, and that's > a clean way to encapsulate it. You've not offered a better > suggestion for how to encapulate it, I'll observe... I've already implemented the shadow budget the way I'm suggesting. The shadow schedule is a list of entries like it is now, but it's not a list of the same entries as on the hardware schedule. Each entry in the shadow schedule is the same type, not one of multiple types connected by a void * or union. It is used primarily for walking and hlding small amounts of private data like now. each shadow schedule entry points to a hardware entry; it may even be a typed pointer if you like (or a normal pointer with a seperate type field, etc). Walking the shadow schedule becomes a typed direct dereference. And, like I said, I have no impetus to change what's there now unless I had some additional reason to replace that much code, which i don't. > matter what your suggestion is, it will _still_ boil down to > managing out-of-band data. Because the "next" pointer from > an ITD has still got to be able to point to an SITD -or- an > ITD -or- a QH; ditto from an SITD. We know that a QH will only > ever point to another QH though. :) Yes, no argument there. But it will mean the oob data is only needed to interpret the hardware schedule, which we're only interested in some of the itme. Most operations are primarily concerned with the shadow schedule. In the interests of limiting the amount of argument going on at the same time, I'm not particularly motivated to keep this one up especially as it's certain to come out to no change to the code in the end. I'm not saying you're wrong and I'm right. It's about style and nothing more (ie, I think I'm *slightly* more right :-) Monty ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
