On Tue, Nov 26, 2002 at 06:37:50PM -0500, Michael Stone wrote: > On Tue, Nov 26, 2002 at 04:26:16PM -0700, Joel Baker wrote: > >I must admit to some confusion, here. Should I take this as implying that > >there is no particular intent to try to make Debian-Installer play nicely > >on anything but Linux kernels? > > I'm saying that some things that an installer does are by their nature > specific to a kernel. Others are not. If the people writing the software > decide that a particular piece is better written to use /proc or /devfs, > then they should use /proc or /devfs without losing a lot of sleep over > it. In the origional message, I merely pointed out that keeping such things properly encapsulated is crucial, if you EVER want to be able to run on any other kernel. > (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. > If you want to support the same functionality on whatever other kernel > you want to use, you'll have to write some (kernel-specific) code to do > so. Does that mean you can't leverage the partitioning tool once a device > is given? Or that you can't use the network config tool once the network > drivers have been loaded? Of course not--so why are you trying to start > some sort of kernel jihad? Have you stopped beating your wife yet? It isn't about a 'kernel jihad', or saying that Linux sucks. It's saying "If you want a Linux specific installer, fine, but tell those of us working on non-Linux ports so we can dump Debian-Installer and work on something that will someday actually install our ports". 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. Three examples: 1) 'Core' /proc, which appears to be the same on all known ports. Still good to have things that use it be tied behind an API (in case there is ever a port that doesn't have it), but whatever is written for the Linux version will probably work just fine on the rest. 2) Sysctl, which on Linux can be found either via 'sysctl' or /proc/sys, but on other OSes is generally only 'sysctl'. If if was written as /proc/sys, I'd probably just rewrite it when I came to it, and suggest that it was a more portable way to access it all (bringing it back into the realm of example #1). 3) Devices for partitioning, which Linux can find via devfs, and the others may or may not be able to imitate so easily - but which, if bound behind an API, becomes an implementation detail, so we write modules to handle this on other OSes. Don't forget to keep assumptions about "what is a valid device name" out of this, though; what you call /dev/hda (or /dev/discs/disc0) I might call 'wd0', or even 'wd0a' (partitions within slices, and other quirks). -- *************************************************************************** Joel Baker System Administrator - lightbearer.com lucifer@lightbearer.com http://users.lightbearer.com/lucifer/
Attachment:
pgpIWz2BvoE7v.pgp
Description: PGP signature