On 7/26/06, John Culp <[EMAIL PROTECTED]> wrote:
> yeah, right... then you need an XML parser in the driver... somehow I > don't think the kernel people will think it's a good idea... > I am in no way shape or form arguing for XML, but: Would not the part that sits in the kernel ideally only need to know how to manage transfers from user space to kernel space and handle errors gracefully? If an invalid command for a non-existent functional unit is invoked by a series of uploaded commands a standard error could be thrown by the hardware and handled by the kernel. X could be entrusted to parse a hardware description and figure out how to best utilize the hardware available. The only bits that would have to be standardized between compatible variants would be the hardware that provides a dumb framebuffer for the kernel managed console, the command/data upload/download hardware, the error handling protocol/mechanism, and perhaps the mechanism for changing video modes. Compared to the total hardware that can exist on the card, this is pretty minimal.
I haven't been following the whole conversation, so I may repeat something, but... The PROM is 1 megabit, which is 128KiB. I think. I don't know how big the firmware is going to be, but it shouldn't be huge. Most of it'll be written in assembly and various sorts of bytecode (OpenBoot, EFI or whatever that Intel thing is, etc.). We should be able to fit in firmware for more than one architecture with room left over. Use it however you like. Some of the info you want to know is going to be available via VPD. Anything else can be placed in some standard location in the PROM so that software can get at it. In any case, since this is all just metadata, there's no need to use more silicon for it. I've never been a fan of XML, although that could be a mental deficiency on my part. Or a background with small memory-limited processors and hardware design. But I have done plenty of application development and web development, so I have had plenty of experience with having to store data, which means you need a format. Given the overhead, I don't see much point in using XML, but you can if you want to. But backing up a bit, why do we want this in the first place? How many "standard" designs for OGD1 would we really have? Actually, it would be great for business if there were lots of them. Sometimes, it would make sense to combine designs. I just don't see it getting so complex that even a simple list of features wouldn't be overkill. How about we use the wiki to define 32-bit identifiers that we put in a zero-terminated list somewhere in the PROM. If you don't know what an identifier is, you can look it up on the wiki. Moreover, most codes would be allocated as 4-letter names that, when viewed as ASCII, may make some kind of sense. Things like: NICx, OGA1, VDIN, ADIO, etc. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
