[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Are we losing users to Gentoo?

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

Reply to: