Date: Sat, 23 Oct 2004 20:56:38 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: Scott Long <scottl@freebsd.org> Cc: current@freebsd.org Subject: Re: Breaking up kernel config files (GENERIC) Message-ID: <p06110433bda0a9094720@[128.113.24.47]> In-Reply-To: <417A17E0.7000800@freebsd.org> References: <417960C2.8040007@freebsd.org> <20041022194008.GA23778@odin.ac.hmc.edu> <41796396.5070804@freebsd.org> <p06110423bd9f1b6312ed@[128.113.24.47]> <41796D6D.7000108@freebsd.org> <41799315.70201@elischer.org> <41799396.9090307@freebsd.org> <20041023082926.GE45235@ip.net.ua> <417A17E0.7000800@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In the thread "Annoying SCSI waiting..."
At 2:35 AM -0600 10/23/04, Scott Long wrote:
>Ruslan Ermilov wrote:
>>On Fri, Oct 22, 2004 at 05:11:18PM -0600, Scott Long wrote:
>>
>>>I'd like to see GENERIC get split into several sub-modules
>>>that live in /sys/conf and can be included instead of
>>>constantly duplicated.
>>>i.e.
>>>
>>>/sys/conf:
>>>/SCSI
>>>/BLOCK
>>>/NIC
>>>/USB
>>>/FIREWIRE
>>>
>>>etc.
>>>
>>>Again, only for HEAD, not for RELENG_5. Thoughts?
>>
>>I've had this idea for quite some time too. But my thought was
>>as far as having the sys/conf/GENERIC, a common portion of all
>>GENERIC configs for all architectures.
>
>I have a feeling that as we expand to things like ARM and possibly
>MIPS that there will be very little that is 'standard' anymore.
>It might be possible to distill some common 'CORE' pieces, but
>we really shouldn't over-engineer this =-)
But I think we should think about it a bit, and figure out what it
is that we "really want". I am not sure what that is yet, but it
would be good to throw around some ideas.
>I've been hacking up config(8) to allow the 'include' directive to
>look outside of the current working directory. Ideally I'd like
>to have a new directive that allows you to specify and/or override
>the default search path for included configs. Unfortunately my
>blissful ignorance towards lex/yacc is starting to show =-)
So, what *do* we want, and what things do we need as we expand our
support to somewhere between six and ten architectures?
I do not know how I would break up *everything*, but let's take a
few easy cases. Say, categories like SCSI or Firewire.
I think it is obvious that GENERIC should default to including
support for all scsi controllers, just so a person can get up and
running on any hardware that we support. But when it comes time to
customize a kernel, what will a person want to do for any category?
Most likely, they want one of two things:
1) Turn off *all* scsi, because they know they have no
scsi card at all.
2) Turn on the scsi card that they have, but turn off all
other scsi cards.
For either case, what I would like is to duplicate the GENERIC kernel,
and then have to modify only one single line to get what I want (one
line per category, that is). Maybe something like:
1) SCSI OFF
2) SCSI ON,ahc
If I know I have ahc (which I can read from dmesg), then I should not
need to learn the full list of possible SCSI controllers. I just need
to know "I have one scsi controller, and it looks like that is called
'ahc', so I will turn on that specific controller and trust that all
other SCSI controllers will be turned off".
How does that sound?
--
Garance Alistair Drosehn = gad@gilead.netel.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p06110433bda0a9094720>