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

Re: does the HURD run on this hardware?



On Sat, Aug 07, 1999 at 11:35:00AM -0400, Michael Bacarella wrote:
> Rather than burden individuals with this whenever the need arises,
> wouldn't it just be better to compile a group of stock kernels that people
> just select based on their configuration?

The problem is that it is unknown what those stock kernels are.
 
> I don't know how hairy the configurations are, though, so this might not
> be as practical.

It is easy to build multiple kernels consecutively. It is easy o configure
one kernel.

But what should the configurations be? Which set of --enable-xxx flags to
gnumach will enable most of the hardware out there? How mayn stock kernels
are needed?

> Alternatively, until dynamically loadable modules become available,

If ever, probably never (for gnumach).

> would
> it be possible to just store the kernel as a collection of (compiler
> output) modules that, oh, a cgi-backend could link together based on a
> user's selected configuration and send it to them?

Why cgi? If a script can do it, we can ship it with a package including
those object files.

There are at least some tables that have a lot of #ifdef...#endif pairs.
 
> Worth the effort? :)

I don't know if this is easily achieved. Another idea would be the
possibility to skip autodetection of some drivers at run time. Let's say,
you can give gnu mach a flag to make the autodetection stage interactive.
Then you can play with several combinations.

This should not be too hard. Just wrap the call to the autodetection
routine. This owuld be especially useful for testing various autodetection
routines that seem to break other drivers on some hardware. This would
indeed be evenmore useful than the *.o linking.

As a next stage, another flag could be used to make the wrapper look into an
array if this driver should be enabled. The array could then be edited with
a hex editor (this can be automatedby a script!).

This would be far from an optimal solution, but would enable us to ship only
one kernel for everybody.

I imagine this:

Do you want to probe for SYMBOL1? [y/n]
y
Do you want to probe for SYMBOL2? [y/n]
n
Do you want to probe for SYMBOL3? [y/n]
n
Do you want to probe for SYMBOL4? [y/n]
y
Do you want to probe for SYMBOL5? [y/n]
y
...
Your configuration is:
10011...

[further booting]

$ configure_kernel "10011..."
$

where the configure_kernel script hex edits the gnumach kernel.

Anybody wants to do this? The biggest problem would be to get the keyboard
input, I think.

Thanks,
Marcus
 
-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org   finger brinkmd@ 
Marcus Brinkmann              GNU    http://www.gnu.org     master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de                        for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/       PGP Key ID 36E7CD09


Reply to: