On Wed, Nov 27, 2002 at 07:05:31AM +0100, Tollef Fog Heen wrote: > * "Joel Baker" > > | > (I can think of one trivial example--devfs makes it really easy to tell > | > which disks are available to the partitioning program. Can you describe > | > a simple method to do that, which is guaranteed to work on any kernel? > | > Likewise, can you describe a kernel-independent way of parsing the pci > | > device table and loading relevant drivers?) > | > | To run with your example... I could care less how it's done on a Linux > | kernel, if the API says "Calling this routine will return a list of device > | names which can be safely handed to the partitioning subsystem". Maybe > | that's devfs on Linux, a Perl script on NetBSD, and green cheese on some > | other system. *As long as the API does not assume anything about the system > | underneath*, it *becomes* the 'simple system to do that on any kernel'. > | That's all I'm asking for - careful API design, that tries very hard to > | *not* make any assumptions about such things, and breaks things down far > | enough that one can safely encapsulate OS-specific ways of doing it such > | that they can be replaced. > > Yes, that's a goal, eventually. We are not there yet. First, get > things working, then make then work and look nice. Trying to do two > things at a time will make you fumble and not do any of them well. I might argue, in the case of APIs, that it is more a case of "If you don't have time to do it right, how will you ever have time to do it over" - it becomes *very* hard to un-entrench bad API choices, a lot of the time. > | On the other hand, if it *is* supposed to support non-Linux ports, all I'm > | asking for is that people try to be mindful of such assumptions and keep > | them hidden as implementation details, rather than core assumptions. > > The core assumption in d-i is debconf and some implementation of > dpkg. Apart from that it is all modules which can be switched at > will. Yes, there are linuxisms and i386isms in the code. Yes, they > will be fixed. However, in contrast to the above, it sounds like you have things split out enough that hopefully it won't come back to bite anyone later, too hard. Specific bits of code are far easier to fix than flawed design. I will grant that my perspective may be skewed; I typically do what programming work I do under folks who prefer lightweight processes (XP and things not quite so lightweight, but close), and for whom not having a clear API means you don't write code - because you have no idea what the code should be doing. -- *************************************************************************** Joel Baker System Administrator - lightbearer.com lucifer@lightbearer.com http://users.lightbearer.com/lucifer/
Attachment:
pgphESKGTyCXE.pgp
Description: PGP signature