ISA hardware discovery -- the elegant solution
Eric S. Raymond
and there may be an elegant solution. It will take a number of small changes
to the kernel sources, however.
The kernel's device drivers have, of course, to include probe
routines, and those hard-compiled in typically log the presence of
their hardware to /var/log/mesg when it loads. By scanning that
file, we in effect get to use those probes.
My autoconfigurator's probe table now has a small number of tests than
do regexp matches against the dmesg log. As is, this solution does not
scale well, because each regexp has to be discovered by eyeball and then
maintained in the table by hand.
But suppose the format of boot-time driver messages were standardized in a
format that included their config symbol in a discoverable form?
I have hand-edited a copy of my current /var/log/dmesg to illustrate
how I think this could work.
:MTRR: your CPUs had inconsistent fixed MTRR settings
:MTRR: probably your BIOS does not setup all CPUs
:PCI: PCI BIOS revision 2.10 entry at 0xfd7c0, last bus=1
:PCI: Using configuration type 1
:PCI: Probing PCI hardware
BIOS disabled PCI ordering compliance, so we enabled it again.
:IO_APIC: AMD Errata #22 may be present. In the event of instability try
: booting with the "noapic" option.
:NET: Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
:RTNETLINK: Initializing RT netlink socket
Starting kswapd
allocated 32 pages and 32 bhs reserved for the highmem bounces
:JBD: Journalled Block Device driver loaded
:UNIX_PTY: 2048 Unix98 ptys configured
block: 128 slots per queue, batch=32
:IDE: Uniform Multi-Platform E-IDE driver Revision: 6.31
:IDE: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
:SCSI: SCSI subsystem driver Revision: 1.00
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.4
<Adaptec aic7899 Ultra160 SCSI adapter>
aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.4
<Adaptec aic7899 Ultra160 SCSI adapter>
aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs
Vendor: IBM-PSG Model: ST318451LW !# Rev: B833
Type: Direct-Access ANSI SCSI revision: 03
Vendor: IBM-PSG Model: ST318451LW !# Rev: B833
Type: Direct-Access ANSI SCSI revision: 03
Vendor: HP Model: C5683A Rev: C005
Type: Sequential-Access ANSI SCSI revision: 02
scsi0:A:0:0: Tagged Queuing enabled. Depth 253
scsi0:A:1:0: Tagged Queuing enabled. Depth 253
Vendor: PIONEER Model: DVD-ROM DVD-305 Rev: 1.00
Type: CD-ROM ANSI SCSI revision: 02
Vendor: PLEXTOR Model: CD-R PX-W1210S Rev: 1.02
Type: CD-ROM ANSI SCSI revision: 02
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
Attached scsi disk sdb at scsi0, channel 0, id 1, lun 0
(scsi0:A:0): 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
SCSI device sda: 35548320 512-byte hdwr sectors (18201 MB)
Partition check:
sda: sda1 sda2 < sda5 >
(scsi0:A:1): 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
SCSI device sdb: 35548320 512-byte hdwr sectors (18201 MB)
sdb: sdb1 sdb2
Attached scsi CD-ROM sr0 at scsi1, channel 0, id 0, lun 0
Attached scsi CD-ROM sr1 at scsi1, channel 0, id 1, lun 0
(scsi1:A:0): 20.000MB/s transfers (20.000MHz, offset 16)
:BLK_DEV_SR: scsi3-mmc drive: 16x/40x cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.12
(scsi1:A:1): 20.000MB/s transfers (20.000MHz, offset 16)
:BLK_DEV_SR: scsi3-mmc drive: 32x/32x writer cd/rw xa/form2 cdda tray
:USB_DEVFS: registered new driver usbdevfs
:USB: registered new driver hub
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 16384 buckets, 128Kbytes
TCP: Hash tables configured (established 262144 bind 65536)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 96k freed
Adding Swap: 1807272k swap-space (priority -1)
:EXT3_FS: FS 2.4-0.9.16, 02 Dec 2001 on sd(8,5), internal journal
:BLK_DEV_MD: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
kjournald starting. Commit interval 5 seconds
:EXT3_FS: FS 2.4-0.9.16, 02 Dec 2001 on sd(8,1), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
:EXT3_FS: FS 2.4-0.9.16, 02 Dec 2001 on sd(8,18), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
:BLK_DEV_ST: Version 20011103, bufsize 32768, wrt 30720, max init. bufs 4, s/g segs 16
Attached scsi tape st0 at scsi0, channel 0, id 2, lun 0
The convention I propose is that at least one line of a driver probe message
should begin with :, followed by the driver config symbol, followed by :.
I am not attached to that particular punctuation, it is simply an unambiguous
way of indicating "this is a config symbol".
With this change, generating a report on ISA hardware and other
facilities configured in at boot time would be trivial. This would
make the autoconfigurator much more capable. Best of all, the only
change required to accomplish this would be safe edits of print format
strings.
I would be willing to generate a patch to implement this change.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
To stay young requires the unceasing cultivation of the ability to
unlearn old falsehoods.
-- Lazarus Long
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Larry McVoy
> :MTRR: probably your BIOS does not setup all CPUs
> :PCI: PCI BIOS revision 2.10 entry at 0xfd7c0, last bus=1
> :PCI: Using configuration type 1
> :PCI: Probing PCI hardware
It's ugly and distracting and if this proposal goes anywhere, move the tag to
end of the line. Then your eyes can scan the output and the tools can scan
the end of the line.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Zwane Mwaikambo
drivers in kernel, and in particular ISA device drivers. Namely because
ISA probes are ugly and require frobbing of memory in the vague hopes of
finding said device there. These probes may put ye old ISA device in a bad
state sometimes even hard locking your box, so chances are if the ISA
probe is in dmesg, the user explicitely decided to load the device. In
which case they already know what they have...
As an aside, i try not to use ISA and elegant in the same sentence ;)
Regards,
Zwane Mwaikambo
Eric W. Biederman
> I've been thinking about the hardware-discovery problem for ISA devices,
> and there may be an elegant solution. It will take a number of small changes
> to the kernel sources, however.
An elegant solution is writing a program like kudzu and placing the
information it generates in a globally accessible place. The problem
is that linux does really have a complete standard hardware database,
and until such a thing is built there are no short cuts, no easy methods
to get it. And there probably never will be guaranteed unprivledged
user space access to the information. The system administrator may
simply not want to let that information go.
The only thing that comes close to what you currently want is
devfs.
dmesg is for people.
As for ISA there is a reason even the enhance version that allows
software discovery is called Plug-and-Pray.
> My autoconfigurator's probe table now has a small number of tests than
> do regexp matches against the dmesg log. As is, this solution does not
> scale well, because each regexp has to be discovered by eyeball and then
> maintained in the table by hand.
ISA is not a software enumerable bus especially not for unprivledged
users. And no amount of complaining will change that. That is why we
have PNP ISA and PCI.
> But suppose the format of boot-time driver messages were standardized in a
> format that included their config symbol in a discoverable form?
If there was an ISA device in your example it might be interesting.
> With this change, generating a report on ISA hardware and other
> facilities configured in at boot time would be trivial. This would
> make the autoconfigurator much more capable. Best of all, the only
> change required to accomplish this would be safe edits of print format
> strings.
It sounds like what you want is an lsmod that lists compiled in
modules.
> I would be willing to generate a patch to implement this change.
Please don't until you understand the problem...
Eric
Eric S. Raymond
> ISA is not a software enumerable bus especially not for unprivledged
> users. And no amount of complaining will change that. That is why we
> have PNP ISA and PCI.
But the kernel itself has to know how to probe and initialize these devices
at boot time, correct? That information is implicitly exported via
/var/log/dmesg -- I'm simply suggesting that it be a little more explicit.
> > But suppose the format of boot-time driver messages were standardized in a
> > format that included their config symbol in a discoverable form?
>
> If there was an ISA device in your example it might be interesting.
Some of the on-board devices on my Tyan Thunder are ISA.
> > With this change, generating a report on ISA hardware and other
> > facilities configured in at boot time would be trivial. This would
> > make the autoconfigurator much more capable. Best of all, the only
> > change required to accomplish this would be safe edits of print format
> > strings.
>
> It sounds like what you want is an lsmod that lists compiled in
> modules.
Would that be feasible without root privileges in order to read kmem?
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
[The disarming of citizens] has a double effect, it palsies the hand
and brutalizes the mind: a habitual disuse of physical forces totally
destroys the moral [force]; and men lose at once the power of
protecting themselves, and of discerning the cause of their
oppression.
-- Joel Barlow, "Advice to the Privileged Orders", 1792-93
Alan Cox
> drivers in kernel, and in particular ISA device drivers. Namely because
> ISA probes are ugly and require frobbing of memory in the vague hopes of
Red Hat for one basically avoids ISA probing in favour of user guidance. We
also use a standard kernel build and the more I think about this the more
I think Erik's tool is trying to be too clever and should simply build
a complete kernel set for the right cpu with the root fs and root fs block
device built into it
Giacomo Catenazzi
> With this change, generating a report on ISA hardware and other
> facilities configured in at boot time would be trivial. This would
> make the autoconfigurator much more capable. Best of all, the only
> change required to accomplish this would be safe edits of print format
> strings.
Better: create a /proc/driver and every driver will register in it.
This file can help some bug report (and not only autoconfigurator).
BTW, my new tests for:
memory (request_mem_region)
io port (request_region)
irq (request_irq)
dma (request_dma)
are nearly completes.
I think every ISA card should registers one of
these resources.
With the check of register_blkdev, register_chrdev
and miscdevices we should have a complete list of the
old ISA devices.
(this would detect only already detected devices,
but autoconfigure is not yet designed for bootfloppies
makers).
With such new test: no patch to kernel and nearly automatic
generation of probes.
Some patch are still welcome. I.e.:
some people with copy+paste have not changes the driver
string. A kernel patch will help distinguish the two drivers.
watchdog: to many driver register as 'watchdog' (or 'serial',
or 'ps2mouse'. This will create some difficulties to
autoconfigurators. A patch will help us (but it would break
other userspace tools?)
giacomo
Michael Lazarou (ETL)
> From: Eric S. Raymond [mailto:e...@thyrsus.com]
> Subject: ISA hardware discovery -- the elegant solution
>
>
> I've been thinking about the hardware-discovery problem for
> ISA devices,
> and there may be an elegant solution. It will take a number
> of small changes
> to the kernel sources, however.
>
> routines, and those hard-compiled in typically log the presence of
> their hardware to /var/log/mesg when it loads. By scanning that
> file, we in effect get to use those probes.
Doesn't this mean that you would need a fully functional kernel
before you get to run the autoconfigurator?
Michael
Giacomo Catenazzi
Michael Lazarou (ETL) wrote:
>>
>>The kernel's device drivers have, of course, to include probe
>>routines, and those hard-compiled in typically log the presence of
>>their hardware to /var/log/mesg when it loads. By scanning that
>>file, we in effect get to use those probes.
>>
>
> Doesn't this mean that you would need a fully functional kernel
> before you get to run the autoconfigurator?
Not a problem. Autoconfiguration is made to help configuring
the kernel, before to compile it. So you need a linux working
machine (actually you can cross-compile).
Our task is to allow user to compile a kernel, with the
needed drivers, without the non used drivers.
If you want a good running kernel image:
check the kernels in your distribution.
If you want to compile a general running kernel:
use the kernel sources in your distribution (
with your distribution's .config), or compile
the std kernel with your distribution's .config
If you want a working kernel to boot Linux in your
old/new/non-x86 machine: check the installation
note of your distribution. Use special kernel (from
your distribution,...)
You see: different task needs different tools.
Maybe we can merge some problems, but how? why?
[I still have a working version of autoconfigure in
shell, if some "boot-floppies" people need some
of our detection.]
But for old ISA cards (and some newer laptop) there is
only one method to find the right *kernel*:
boot and try (and changing kernels, parameters,...)
[check: installation document and internet resources].
We don't want a boot and retry for our configuration,
so let use the (incomplete) infos from kernel.
giacomo
Zwane Mwaikambo
> Red Hat for one basically avoids ISA probing in favour of user guidance. We
> also use a standard kernel build and the more I think about this the more
> I think Erik's tool is trying to be too clever and should simply build
> a complete kernel set for the right cpu with the root fs and root fs block
> device built into it
I'm definately not a fan of automagic kernel configurations, there are way
too many variables. Frankly the way i see it distro kernels do a damn good
job as it is right now and i don't see anything wrong with going the RH
errata kernel style for upgrading kernels (ditto for Debian and their apt
kernel upgrades). All Aunt Tillie has to do is click on the update button.
Are ISA device questions really that much of a big problem? The way i see
it, the user would get flooded more with the plethora of PCI and USB
devices more than anything. Then again i might be missing the "Big
Picture" ;)
Regards,
Zwane Mwaikambo
Michael Lazarou (ETL)
> From: Giacomo Catenazzi [mailto:ca...@debian.org]
> >>
> >>The kernel's device drivers have, of course, to include probe
> >>routines, and those hard-compiled in typically log the presence of
> >>their hardware to /var/log/mesg when it loads. By scanning that
> >>file, we in effect get to use those probes.
> >>
> >
> > Doesn't this mean that you would need a fully functional kernel
> > before you get to run the autoconfigurator?
>
>
> Not a problem. Autoconfiguration is made to help configuring
> the kernel, before to compile it. So you need a linux working
> machine (actually you can cross-compile).
>
> Our task is to allow user to compile a kernel, with the
> needed drivers, without the non used drivers.
OK, well I guess I am a little confused.
If I hit an autoconfigurator button then I would expect a kernel that
will boot and know everything there is to know about my machine.
Without probing the hardware how will the autoconfigurator cope with
the hardware changing underneath it?
Michael
Giacomo Catenazzi
Michael Lazarou (ETL) wrote:
>>Not a problem. Autoconfiguration is made to help configuring
>>the kernel, before to compile it. So you need a linux working
>>machine (actually you can cross-compile).
>>
>>Our task is to allow user to compile a kernel, with the
>>needed drivers, without the non used drivers.
>>
>
> OK, well I guess I am a little confused.
>
> If I hit an autoconfigurator button then I would expect a kernel that
> will boot and know everything there is to know about my machine.
Actually there is no yet 'autoconfigurator button'.
I recommend to run a std configuration tool and to check
the configuration before the kernel build phase.
> Without probing the hardware how will the autoconfigurator cope with
> the hardware changing underneath it?
We probe the hardware (but in a soft manner).
Better: we probe nothing, we ask kernel to give us the results
of already done kernel probes. Thus we never hang, we never crash
machine, no 10-15 reboots to install a new kernel.
The good news: this is nearly enought.
Linux is magic: it can do infinite loops in 5 sec, but also
it can configure automatically a new kernel without real hardware
probes!.
giacomo
Eric S. Raymond
> Doesn't this mean that you would need a fully functional kernel
> before you get to run the autoconfigurator?
Yes, but this was always true.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
You need only reflect that one of the best ways to get yourself a
reputation as a dangerous citizen these days is to go about repeating
the very phrases which our founding fathers used in the great struggle
for independence. -- Attributed to Charles Austin Beard (1874-1948)
Giacomo Catenazzi
Eric S. Raymond wrote:
> Giacomo Catenazzi <ca...@debian.org>:
>
>>>With this change, generating a report on ISA hardware and other
>>>facilities configured in at boot time would be trivial. This would
>>>make the autoconfigurator much more capable. Best of all, the only
>>>change required to accomplish this would be safe edits of print format
>>>strings.
>>>
>>
>>Better: create a /proc/driver and every driver will register in it.
>>This file can help some bug report (and not only autoconfigurator).
>>
>
> That would be fine with me. But wouldn't it involve adding a new
> initialization-time call to every driver.
I think we can add it automatically, modifing one of the
the modules macros. (this works automatically only for
trit symbols).
Hmm. IIRC there is a big module/driver API (for modules) change
in 2.5 programs (driver registration,...). In this case we should
only modify the API before it will be effectivelly used, and
the changes will go automatically in kernel...
giacomo
Eric S. Raymond
> >>Better: create a /proc/driver and every driver will register in it.
> >>This file can help some bug report (and not only autoconfigurator).
> >
> > That would be fine with me. But wouldn't it involve adding a new
> > initialization-time call to every driver.
>
> I think we can add it automatically, modifing one of the
> the modules macros. (this works automatically only for
> trit symbols).
That would be OK. I think there are *very* few drivers left that
aren't modular.
> Hmm. IIRC there is a big module/driver API (for modules) change
> in 2.5 programs (driver registration,...). In this case we should
> only modify the API before it will be effectivelly used, and
> the changes will go automatically in kernel...
This sounds encouraging.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Ideology, politics and journalism, which luxuriate in failure, are
impotent in the face of hope and joy.
-- P. J. O'Rourke
Eli Carter
>
> Michael Lazarou (ETL) <Michael...@etl.ericsson.se>:
> > Doesn't this mean that you would need a fully functional kernel
> > before you get to run the autoconfigurator?
>
> Yes, but this was always true.
And if the reason you are building a new kernel is that the old one is
mis-identifying some of your hardware? ;)
Could you maybe describe the problem you are trying to solve a bit more
clearly than "the hardware-discovery problem for ISA devices"? If you
are trying to discover the ISA devices, but rely upon them having
already been discovered, what are you accomplishing?
Puzzled,
Eli
--------------------. Real Users find the one combination of bizarre
Eli Carter \ input values that shuts down the system for days.
eli.carter(a)inet.com `-------------------------------------------------
Wichert Akkerman
Eli Carter <eli.c...@inet.com> wrote:
>Could you maybe describe the problem you are trying to solve a bit more
>clearly than "the hardware-discovery problem for ISA devices"? If you
>are trying to discover the ISA devices, but rely upon them having
>already been discovered, what are you accomplishing?
The problem is that it is simply not possible to identify ISA devices
if they aren't isapnp devices. The only thing you can do is try to
probe for them by poking at different addresses and checking what happens.
Unfortunately this can do any of three things: show that a piece of
hardware exists, show that it is not there or completely crash your
machine if another unpexpected piece of hardware happens to be at the
place you are poking.
The best approach to doing ISA detection is ask the user which
devices he thinks he has installed and try looking for them while
praying bad things won't happen.
Wichert.
--
_________________________________________________________________
/ Nothing is fool-proof to a sufficiently talented fool \
| wic...@wiggy.net http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Eric S. Raymond
> > With this change, generating a report on ISA hardware and other
> > facilities configured in at boot time would be trivial. This would
> > make the autoconfigurator much more capable. Best of all, the only
> > change required to accomplish this would be safe edits of print format
> > strings.
>
> Better: create a /proc/driver and every driver will register in it.
> This file can help some bug report (and not only autoconfigurator).
That would be fine with me. But wouldn't it involve adding a new
initialization-time call to every driver.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
The whole of the Bill [of Rights] is a declaration of the right of the
people at large or considered as individuals... It establishes some
rights of the individual as unalienable and which consequently, no
majority has a right to deprive them of.
-- Albert Gallatin, Oct 7 1789
Eric W. Biederman
> Eric W. Biederman <ebie...@xmission.com>:
> > ISA is not a software enumerable bus especially not for unprivledged
> > users. And no amount of complaining will change that. That is why we
> > have PNP ISA and PCI.
>
> But the kernel itself has to know how to probe and initialize these devices
> at boot time, correct? That information is implicitly exported via
> /var/log/dmesg -- I'm simply suggesting that it be a little more explicit.
For ISA not necessarily. It could simply be told that it was there.
/etc/modules.conf or it's compile time equivalent.
> > > But suppose the format of boot-time driver messages were standardized in a
> > > format that included their config symbol in a discoverable form?
> >
> > If there was an ISA device in your example it might be interesting.
>
> Some of the on-board devices on my Tyan Thunder are ISA.
I agree that ISA is a case. I simply didn't see it. And that was
my real point. Usually we are pretty silent about most ISA devices in
dmesg, because of most of them are mandated by the PC architecture and
we just expect them to be there.
> > > With this change, generating a report on ISA hardware and other
> > > facilities configured in at boot time would be trivial. This would
> > > make the autoconfigurator much more capable. Best of all, the only
> > > change required to accomplish this would be safe edits of print format
> > > strings.
> >
> > It sounds like what you want is an lsmod that lists compiled in
> > modules.
>
> Would that be feasible without root privileges in order to read kmem?
Given that nothing in the linux world reads kmem...
Honestly you have two separate problems.
Problem 1: How do you find out all of the hardware you have, as root.
Problem 2: How do you get that information as non-root.
Please try solving these problems separately.
Eric
Alan Cox
> initialization-time call to every driver.
man lsmod
Mr. James W. Laferriere
Hello All , And what mechanism is going to be used for an -all-
compiled in kernel ? Everyone and there brother is so enamoured
of Modules . Not everyone uses nor will use modules .
Tia , JimL
On Mon, 14 Jan 2002, Alan Cox wrote:
+------------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network Engineer | P.O. Box 854 | Give me Linux |
| bab...@baby-dragons.com | Coudersport PA 16915 | only on AXP |
+------------------------------------------------------------------+
Alan Cox
> compiled in kernel ? Everyone and there brother is so enamoured
> of Modules . Not everyone uses nor will use modules .
For 2.5 if things go to plan there will be no such thing as a "compiled in"
driver. They simply are not needed with initramfs holding what were once the
"compiled in" modules.
Alan
Eric S. Raymond
> Could you maybe describe the problem you are trying to solve a bit more
> clearly than "the hardware-discovery problem for ISA devices"? If you
> are trying to discover the ISA devices, but rely upon them having
> already been discovered, what are you accomplishing?
Sure. Let's say Aunt Tillie needs a kernel update.
Aunt Tillie is running a distro kernel (modular everything) on the
machine her nephew Melvin bought her last year. The distro kernel
knows about the ISA devices on the machine.
She complains of occasional lockups, and that she gets skips when
playing her Guy Lombardo MP3s. Melvin says, over the phone: "Yup,
that version had some VM problems. And you need the low-latency stuff
that went in three releases ago. But never mind the technical stuff.
Just click on the 'kernel update' icon on your desktop." Melvin is
500 miles away at college.
Aunt Tillie clicks. She sees a message saying "Downloading kernel
sources" and a progress bar. Under the hood, the mchine is downloading
the tip of the stable branch from a kernel.org mirror site.
So why doesn't she use Red Hat or Mandrake's RPM update? Maybe she's
running something else. (You ain't going to tell me Aunt Tillie is ready
for Debian apt-get, either.) Maybe she wants a kernel that's compiled
for her AMD Athlon K6 rather than a 386. OK, so she doesn't know what
processor she has, she just remembers that Melvin told her you get a
faster kernel when you build it yourself.
(Aunt Tillie probably thinks having a faster kernel will mean she can
download images from her favorite knitting-pattern website more
quickly. Aunt Tillie is a little confused about the difference
between processor and network speed. That's OK; well-designed
technology should allow people the luxury of ignorance.)
Then the progress window changes to a message that says
"Configuring..." and some information about her hardware. This is the
autoconfigurator running inside a GUI shell.
Then it says "Building..." and another progress bar. Finally it says
"Please enter your root password so I can install the new kernel".
And, once she's done that, it tells her "Your new kernel will be named
'Sapphire' on your boot screen. Shall I reboot now?" She clicks "Yes".
Her machine reboots. She selects "Sapphire" on her boot screen. The
new kernel boots. She logs in. She surfs to her knitting-pattern
website. She logs out.
When she clicks "Shutdown", a popup says "This is not the same kernel
that will come up by default when you next boot. Should I make it the
default?" She clicks "Yes". Her kernel upgrade is done. It required
just four mouse clicks and one password entry. At no point did she
have to retain mental state about previous stages of the upgrade.
(Aunt Tillie is getting on in years; she isn't as good at retaining
abstract facts as she used to be.)
In fact, at a pinch we could have done away with the password entry,
presuming that anyone with physical access to the console is allowed
to perform canned administrative functions (though not to a root
shell).
We have the technology to do all of this now; the autoconfigurator is
the last nontrivial missing piece. And if we truly want world
domination, this is what it's going to take -- ease of use that is
Macintosh-like or better at *every* level of system use and
administration.
It takes a different way of thinking than most hackers are used to.
We're proud of our mad programming skillz and our ability to wrestle
with arcana. That pride isn't a bad thing -- except when it gets in
the way of designing systems that Aunt Tillie can use.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Sometimes the law defends plunder and participates in it. Sometimes the law
places the whole apparatus of judges, police, prisons and gendarmes at the
service of the plunderers, and treats the victim -- when he defends himself --
as a criminal. -- Frederic Bastiat, "The Law"
Eric S. Raymond
> > That would be fine with me. But wouldn't it involve adding a new
> > initialization-time call to every driver.
>
> man lsmod
I couldn't make any sense at all out of this until your later posting
saying that compiled-in drivers are going away when initramfs comes in.
You might try being a *little* less terse...
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Love your country, but never trust its government.
-- Robert A. Heinlein.
Alan Cox
> running something else. (You ain't going to tell me Aunt Tillie is ready
> for Debian apt-get, either.) Maybe she wants a kernel that's compiled
I've seen apt-get used successfully by people whom I wouldnt trust to have
a glass front door in case they forgot to open it. The trick being that
"upgrade" is a desktop item someone put there that runs apt for them (or
gnome-apt or kpackage)
Now to do everything you describe does not need her to configure a custom
kernel tree. Not one bit. You think apt or up2date build each user a custom
kernel tree ?
You basically build everything modular as the distro kernel did, you install
it as the distro kernel would. You build an initrd as the distro kernel did.
Not only does it work, but it needs no configuration because when the box
was installed someone already configured it
Alan Cox
> saying that compiled-in drivers are going away when initramfs comes in.
> You might try being a *little* less terse...
why ? 8)
(and yes that was meant to be a joke)
Alan
Eric S. Raymond
> For 2.5 if things go to plan there will be no such thing as a "compiled in"
> driver. They simply are not needed with initramfs holding what were once the
> "compiled in" modules.
This is something of a bombshell. Not necessarily a bad one, but...
Alan, do you have *any* *freakin'* *idea* how much more complicated
the CML2 deduction engine had to be because the basic logical entity
was a tristate rather than a bool? If this plan goes through, I'm
going to be able to drop out at least 20% of the code, with most of
that 20% being in the nasty complicated bits where the maintainability
improvement will be greatest. And I can get rid of the nasty "vitality"
flag, which probably the worst wart on the language.
Yowza...so how soon is this supposed to happen?
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Government should be weak, amateurish and ridiculous. At present, it
fulfills only a third of the role. -- Edward Abbey
Oliver Xymoron
> Michael Lazarou (ETL) <Michael...@etl.ericsson.se>:
> > Doesn't this mean that you would need a fully functional kernel
> > before you get to run the autoconfigurator?
>
> Yes, but this was always true.
No it's not. You only need a kernel that can run your compiler.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
Stephen Shirley
If, as Alan described, you can depend on the distro's installation
program to have automatically identified all the hardware possible,
and for the user to have specified and additional (i.e. isa etc)
devices, then could not the autoconfigurator simply see what drivers
are currently in use (via /proc/devices etc), check
/etc/modules.conf for any that don't happen to be loaded at the
time, and use that info to configure the new kernel. Unless there is
some new piece of hardware that the new kernel supports that is
present (and isn't supported by the old one), if linux was installed
properly, you now have all the info you need, no? This removes the
need for the configurator to do any sort of probing, neither are
root proviledges required. Anyway, that's all probably blatantly
obvious etc, so I'll just be quiet now.
Steve
--
"My mom had Windows at work and it hurt her eyes real bad"
Dave Jones
> She complains of occasional lockups, and that she gets skips when
> playing her Guy Lombardo MP3s. Melvin says, over the phone: "Yup,
> that version had some VM problems. And you need the low-latency stuff
> that went in three releases ago.
... and the 200 patches that the vendor added that she's become
so used to just being there...
> Just click on the 'kernel update' icon on your desktop."
*sigh*, and the package updater to get a new kernel for $distro
is insufficient because ?
distro kernel update has the following advantages.
- Comes complete with the 200 patches already applied.
- Is _tested_ by $distrovendor.
- If it screws up, and Aunt Tillie shelled out for support
(which of course, she did being the 'needing support' type)
$distrovendor will help. Ringing support and saying "Melvin
told me to install a new kernel, and now my box doesn't boot"
may not be a supportable scenario for all vendors.
> So why doesn't she use Red Hat or Mandrake's RPM update? Maybe she's
> running something else.
Red Hat & Mandrake are not the only distros with online update,
in fact, it's probably considered a must-have feature for most
distros these days.
> (You ain't going to tell me Aunt Tillie is ready
> for Debian apt-get, either.)
Wait a minute. Not ready for 'apt-get', but ready to build & run a
kernel made up of a collection of random patches on Melvin's say-so ?
> Maybe she wants a kernel that's compiled
> for her AMD Athlon K6 rather than a 386.
Various distro vendors update facilities give you this option.
> OK, so she doesn't know what processor she has
Some even autodetect.
> We have the technology to do all of this now;
Indeed. It's called YaST, Red Carpet, Mandrake Update, apt-get,
apt-rpm, and a plethora of other such tools.
> It takes a different way of thinking than most hackers are used to.
Yup. One where reinventing the wheel seems appropriate.
> We're proud of our mad programming skillz and our ability to wrestle
> with arcana. That pride isn't a bad thing -- except when it gets in
> the way of designing systems that Aunt Tillie can use.
The systems are designed, and the punchline is, that they work,
and they're being used out there today.
Dave.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
Eric S. Raymond
> Now to do everything you describe does not need her to configure a custom
> kernel tree. Not one bit. You think apt or up2date build each user a custom
> kernel tree ?
Is it OK in your world that Aunt Tillie is dependent on a distro maker? Is
it OK that she never gets to have a kernel compiled for anything above the
least-common-denominator chip?
Not that I'm running down distro makers. They do a valuable job, and in fact
my approach relies on Aunt Tillie's machine starting life with an all-modular
distro kernel.
But the point of this game is for Aunt Tillie to have more and better
choices. Isn't that what we're supposed to be about?
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Government should be weak, amateurish and ridiculous. At present, it
fulfills only a third of the role. -- Edward Abbey
Alan Cox
> improvement will be greatest. And I can get rid of the nasty "vitality"
> flag, which probably the worst wart on the language.
>
> Yowza...so how soon is this supposed to happen?
Subject to availability. No contract implied or etc.. Its something to
tackle after the rest of initramfs works. Even if not then the lsmod case
can be made to work since its just a matter of putting the names in a segment
for the linker to collate.
We already have module_init/module_exit which is a big chunk of the cleanup.
Alan Cox
> it OK that she never gets to have a kernel compiled for anything above the
> least-common-denominator chip?
The two don't follow.
The goal of a typical end user is "make it work, make it go away and do what
it did last week". Random mechanics hating car owners don't do engine tuning
jobs or fit turbochargers.
Secondly we've established we can pick the right CPU for the kernel reliably
that is seperate to modules.
Thirdly building a lot of stuff modular is the right choice anyway - in the
world of hot plugging and USB Grandma is not going to want to recompile her
kernel because she bought a new trackball to boost her quake score.
Alan
David Lang
1. security, if you don't need any modules you can disable modules entirly
and then it's impossible to add a module without patching the kernel first
(the module load system calls aren't there)
2. speed, there was a discussion a few weeks ago pointing out that there
is some overhead for useing modules (far calls need to be used just in
case becouse the system can't know where the module will be located IIRC)
3. simplicity in building kernels for other machines. with a monolithic
kernel you have one file to move (and a bootloader to run) with modules
you have to move quite a few more files.
modules are good for distros and for machines that have to worry about
hotpluged equipment (but even that is less nessasary then it used to be)
but for servers that don't change their hardware they aren't nessasary,
why should they have to deal with them?
David Lang
On Mon, 14 Jan 2002, Eric S. Raymond wrote:
> Date: Mon, 14 Jan 2002 13:10:50 -0500
> From: Eric S. Raymond <e...@thyrsus.com>
> To: Alan Cox <al...@lxorguk.ukuu.org.uk>
> Cc: Mr. James W. Laferriere <bab...@baby-dragons.com>,
> Giacomo Catenazzi <ca...@debian.org>,
> Linux Kernel List <linux-...@vger.kernel.org>
> Subject: Hardwired drivers are going away?
Alan Cox
> and then it's impossible to add a module without patching the kernel first
> (the module load system calls aren't there)
Urban legend.
> 2. speed, there was a discussion a few weeks ago pointing out that there
> is some overhead for useing modules (far calls need to be used just in
> case becouse the system can't know where the module will be located IIRC)
I defy you to measure it on x86
> 3. simplicity in building kernels for other machines. with a monolithic
> kernel you have one file to move (and a bootloader to run) with modules
> you have to move quite a few more files.
tar or nfs mount; make modules_install.
Eric S. Raymond
> > Yowza...so how soon is [the end of hard-compiled drivers] supposed to
>
> Subject to availability. No contract implied or etc.. Its something to
> tackle after the rest of initramfs works.
Dang. This will make the CML2 inference engine work better in some
funky corner cases, too. And its behavior will be easier to
understand all around.
Sign me up. This will be a good change; I like it when I can make things
better by taking features *out* of my code.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Every Communist must grasp the truth, 'Political power grows out of
the barrel of a gun.'
-- Mao Tse-tung, 1938, inadvertently endorsing the Second Amendment.
Charles Cazabon
> Alan Cox <al...@lxorguk.ukuu.org.uk>:
> > Now to do everything you describe does not need her to configure a custom
> > kernel tree. Not one bit. You think apt or up2date build each user a custom
> > kernel tree ?
>
> Is it OK in your world that Aunt Tillie is dependent on a distro maker? Is
> it OK that she never gets to have a kernel compiled for anything above the
> least-common-denominator chip?
Yes, and yes. Aunt Tillie is running Linux because someone installed a
distribution for her.
She is never going to need anything out of her kernel that her vendor-shipped
update kernels do not provide. She is never going to need the 1% performance
difference she might she if she custom-compiled a kernel for her architecture
rather than using the closest one shipped by her vendor.
> But the point of this game is for Aunt Tillie to have more and better
> choices. Isn't that what we're supposed to be about?
No. We're supposed to be about stuff that works. Vendor-shipped kernels work
for 99.9% of people. The remaining 0.1% have no need for an
"auto-configurator".
Charles
--
-----------------------------------------------------------------------
Charles Cazabon <char...@discworld.dyndns.org>
GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/
-----------------------------------------------------------------------
Larry McVoy
> Secondly we've established we can pick the right CPU for the kernel reliably
> that is seperate to modules.
Yup, I noticed this when I did a RH 7.2 install recently, pretty spiffy.
And it seems to work, 7.2 "feels" faster, especially groff for some reason
I don't understand.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Mr. James W. Laferriere
Hello Alan ,
On Mon, 14 Jan 2002, Alan Cox wrote:
> > 1. security, if you don't need any modules you can disable modules entirly
> > and then it's impossible to add a module without patching the kernel first
> > (the module load system calls aren't there)
>
> Urban legend.
I do not agree . Got proof ? Yes that is a valid question .
> > 2. speed, there was a discussion a few weeks ago pointing out that there
> > is some overhead for useing modules (far calls need to be used just in
> > case becouse the system can't know where the module will be located IIRC)
> I defy you to measure it on x86
OK ,How about sparc-64/alpha/ia64/... ?
> > 3. simplicity in building kernels for other machines. with a monolithic
> > kernel you have one file to move (and a bootloader to run) with modules
> > you have to move quite a few more files.
> tar or nfs mount; make modules_install.
Please my laugh'o meter is stuck already . Sorry . JimL
+------------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network Engineer | P.O. Box 854 | Give me Linux |
| bab...@baby-dragons.com | Coudersport PA 16915 | only on AXP |
+------------------------------------------------------------------+
-
Alan Cox
> > jobs or fit turbochargers.
>
> kernel should be as simple as changing your oil.
Yeah. I go to the garage versus I click "up 2 date". I don't mix custom
oils.
> > Secondly we've established we can pick the right CPU for the kernel reliably
> > that is seperate to modules.
>
> Right, but that doesn't get you a recompiled binary with extended instructions
> in it.
It does. Once you have picked the required processor type you will get the
right instructions. Except for the Athlon, Winchip and maybe the PIV
I've seen little evidence it matters. The Debian folk claim its worth < 1%
and I don't doubt them.
David Lang
> > 1. security, if you don't need any modules you can disable modules entirly
> > and then it's impossible to add a module without patching the kernel first
> > (the module load system calls aren't there)
>
> Urban legend.
>
If this is the case then why do I get systemcall undefined error messages
when I make a mistake and attempt to load a module on a kernel without
modules enabled?
> > 2. speed, there was a discussion a few weeks ago pointing out that there
> > is some overhead for useing modules (far calls need to be used just in
> > case becouse the system can't know where the module will be located IIRC)
>
> I defy you to measure it on x86
during the discussion a few weeks ago there were people pointing out cases
where this overhead would be a problem.
> > 3. simplicity in building kernels for other machines. with a monolithic
> > kernel you have one file to move (and a bootloader to run) with modules
> > you have to move quite a few more files.
>
> tar or nfs mount; make modules_install.
>
not on my firewalls thank you.
David Lang
Alan Cox
> I do not agree . Got proof ? Yes that is a valid question .
Most of the rootkit type stuff I see nowdays includes code for loading
patches into module free kernels. Its a real no win. The better ones support
regexp scanning so they can patch kernels where the sysadmin thinks he/she
is cool and has hidden or crapped in System.map
> > > case becouse the system can't know where the module will be located IIRC)
> > I defy you to measure it on x86
> OK ,How about sparc-64/alpha/ia64/... ?
Not generally found in your grandmothers PC
> > > 3. simplicity in building kernels for other machines. with a monolithic
> > > kernel you have one file to move (and a bootloader to run) with modules
> > > you have to move quite a few more files.
> > tar or nfs mount; make modules_install.
> Please my laugh'o meter is stuck already . Sorry . JimL
Then fix it, because the above works well. Also remember that autoconfig
tools won't be able to guess remote machines very well 8)
Alan Cox
>
> If this is the case then why do I get systemcall undefined error messages
> when I make a mistake and attempt to load a module on a kernel without
> modules enabled?
Because you are using insmod. The guys who break into your computer probably
are not in their own language "that lame".
> > I defy you to measure it on x86
>
> during the discussion a few weeks ago there were people pointing out cases
> where this overhead would be a problem.
TLB miss overhead for kernel modules is very very hard to measure, at least
on the x86 platform. It can be an issue in userspace as you address much
larger objects and in certain cases like scanning an element in an array
of objects hit a TLB reload each scan or two (think about vertical line draw
unaccelerated in X11)
> > tar or nfs mount; make modules_install.
> >
> not on my firewalls thank you.
If you are that worried just burn a new root file system on CD when you
upgrade your firewall. At least I hope if you are going to pretend to be
so secure that tar is a bad idea you have no writable file store on the
machine ?
Alan
Alexander Viro
On Mon, 14 Jan 2002, Eric S. Raymond wrote:
> Alan Cox <al...@lxorguk.ukuu.org.uk>:
> > For 2.5 if things go to plan there will be no such thing as a "compiled in"
> > driver. They simply are not needed with initramfs holding what were once the
> > "compiled in" modules.
>
> This is something of a bombshell. Not necessarily a bad one, but...
>
> Alan, do you have *any* *freakin'* *idea* how much more complicated
> the CML2 deduction engine had to be because the basic logical entity
> was a tristate rather than a bool? If this plan goes through, I'm
> going to be able to drop out at least 20% of the code, with most of
> that 20% being in the nasty complicated bits where the maintainability
> improvement will be greatest. And I can get rid of the nasty "vitality"
> flag, which probably the worst wart on the language.
>
> Yowza...so how soon is this supposed to happen?
Two technical obstacles:
a) on some architecures modular code is slower (IIRC, the problem is
with medium-range calls being faster than far ones and usable only in the
kernel proper). We probaly want to leave a gap after the .text and remap
.text of module in there - if I understand the problem that should be
enough, but that's really a question to folks dealing with these ports (PPC64
and Itanic?)
b) current differences between options parsing in case of built-in
and modular drivers.
The rest is trivial and should be done in 2.5.4-pre* or so.
But it still leaves you with tristate - instead of yes/module/no it's
yes/yes, but don't put it on initramfs/no. However, dependencies become
simpler - all you need is "I want this, that and that on initramfs" and
the rest can be found by depmod (i.e. configurator doesn't have to deal
with "FOO goes on initramfs (== old Y), so BAR and BAZ must go there
(== can't be M)").
Eric S. Raymond
> Yes, and yes. Aunt Tillie is running Linux because someone installed a
> distribution for her.
You don't know that. Maybe she installed it herself.
> She is never going to need anything out of her kernel that her vendor-shipped
> update kernels do not provide.
*You can't know that.*
And your belief that you *can* know it is a key part of the elitist
developer psychology and implicit assumptions that keeps Linux mostly
inaccessible to the Aunt Tillies of the world.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
According to the National Crime Survey administered by the Bureau of
the Census and the National Institute of Justice, it was found that
only 12 percent of those who use a gun to resist assault are injured,
as are 17 percent of those who use a gun to resist robbery. These
percentages are 27 and 25 percent, respectively, if they passively
comply with the felon's demands. Three times as many were injured if
they used other means of resistance.
-- G. Kleck, "Policy Lessons from Recent Gun Control Research,"
Law and Contemporary Problems 49, no. 1. (Winter 1986.): 35-62.
Mr. James W. Laferriere
Hello Alan ,
On Mon, 14 Jan 2002, Alan Cox wrote:
> > > Urban legend.
> > I do not agree . Got proof ? Yes that is a valid question .
> Most of the rootkit type stuff I see nowdays includes code for loading
> patches into module free kernels. Its a real no win. The better ones support
> regexp scanning so they can patch kernels where the sysadmin thinks he/she
> is cool and has hidden or crapped in System.map
Same as I am seeing . This does not eleviate the fact that
modules can & are a still a security issue . Yes , sloppy
administration is still the biggest culprit in 'most' compromises .
> > > > case becouse the system can't know where the module will be located IIRC)
> > > I defy you to measure it on x86
> > OK ,How about sparc-64/alpha/ia64/... ?
> Not generally found in your grandmothers PC
No, But it is -mine- ! If I can not have complete control over
my system due to the way the Fathers of this operating system
are taking it I will have no choice but to use another or be stuck
at a non-maintained version . Now mind you I LIKE LINUX !
> > > > 3. simplicity in building kernels for other machines. with a monolithic
> > > > kernel you have one file to move (and a bootloader to run) with modules
> > > > you have to move quite a few more files.
> > > tar or nfs mount; make modules_install.
> > Please my laugh'o meter is stuck already . Sorry . JimL
> Then fix it, because the above works well. Also remember that autoconfig
> tools won't be able to guess remote machines very well 8)
Show me , Please . I am not convinced . I shall try out the new
level of kernel without a doubt . But , I find the concept that
-everything- is dynamic to be wrong . Mind you My opinion .
Twyl , JimL
+------------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network Engineer | P.O. Box 854 | Give me Linux |
| bab...@baby-dragons.com | Coudersport PA 16915 | only on AXP |
+------------------------------------------------------------------+
-
Andrew Pimlott
> Michael Lazarou (ETL) <Michael...@etl.ericsson.se>:
> > Doesn't this mean that you would need a fully functional kernel
> > before you get to run the autoconfigurator?
>
> Yes, but this was always true.
I think the point people are getting at is: If you're re-detecting
things that have already been detected, doesn't it seem you're going
about the problem the wrong way?
Most distributors need to solve essentially the same problem you're
solving (detect hardware and install drivers), but without compiling
a kernel (if only to spare the user the wait). To the extent that
they are successful (and they will presumably put considerable
effort into it), your compile-time probes are superfluous--you're
better off piggy-backing on the distribution's hardware detection.
Eg, derive your .config from the modules the distribution has
decided to load, or--even simpler--just compile a kernel with the
same .config as the distributor's kernel, and let the boot-time
scripts take care of the rest. The drawback is that this differs
across distributions--but see below.
Even if you can usually do a better job, you have two major
handicaps: One, you may have to repeat questions that the
distribution already asked, annoying the user. Two, if you ever
screw up something the distribution had working, the user will curse
you.
Which leads me to conclude that your compile-time autodetection,
while cool, is a dead-end as far as helping Cousin Billie (though I
do support the ultimate goal of letting him compile a kernel).
There are some scenarios where you win, but not enough IMO.
To correct this, retarget the project to solve the distributors'
problem. Ie, add a back-end that specifies modules and module
options, instead of a kernel .config. Assuming you do a good enough
job, and meet the distributor's other requirements (eg, running in
an install environment), then they will use your system for their
install-time hardware detection. You can store the results in a
standard (across distributions!) format, which administrators will
love (and which can be used by various to-be-written utilities).
Finally, you can later use the same database for compiling a
"stripped-down" custom kernel.
Andrew
Andrew Pimlott
> On Mon, 14 Jan 2002, Alan Cox wrote:
>
> > > 1. security, if you don't need any modules you can disable modules entirly
> > > and then it's impossible to add a module without patching the kernel first
> > > (the module load system calls aren't there)
> >
> > Urban legend.
>
> If this is the case then why do I get systemcall undefined error messages
> when I make a mistake and attempt to load a module on a kernel without
> modules enabled?
It's an urban legend that this is a security benefit. grep the
hacker zines for injecting code into a non-modular kernel.
> > > 2. speed, there was a discussion a few weeks ago pointing out that there
> > > is some overhead for useing modules (far calls need to be used just in
> > > case becouse the system can't know where the module will be located IIRC)
> >
> > I defy you to measure it on x86
^^^^^^^^^^
> during the discussion a few weeks ago there were people pointing out cases
> where this overhead would be a problem.
Above.
> > > 3. simplicity in building kernels for other machines. with a monolithic
> > > kernel you have one file to move (and a bootloader to run) with modules
> > > you have to move quite a few more files.
> >
> > tar or nfs mount; make modules_install.
> >
> not on my firewalls thank you.
You won't install tar on your firewalls? Weird :-)
Andrew
Alan Cox
> with medium-range calls being faster than far ones and usable only in the
> kernel proper). We probaly want to leave a gap after the .text and remap
Also with TLB mapping sizes (4Mb versus 4K)
> .text of module in there - if I understand the problem that should be
> enough, but that's really a question to folks dealing with these ports (PPC64
> and Itanic?)
For x86 you just need to leave a nice chunk of physical memory that is there
to copy the module text/data into as you insmod them during boot then give
the rest of the pool back to the paging system. This also solves the problem
with "can't be a module because I need 1Mb of linear space" drivers.
Alan
ar...@fenrus.demon.nl
> Not that I'm running down distro makers. They do a valuable job, and in fact
> my approach relies on Aunt Tillie's machine starting life with an all-modular
> distro kernel.
> But the point of this game is for Aunt Tillie to have more and better
> choices. Isn't that what we're supposed to be about?
While I'm absolutely not disputing the right of anyone to compile their own
kernel (I'm not trying to lock customers into my special platform like some
unnamed industrial giant *cough*), I just wonder why an AUTOMATIC generated
kernel with all the _relevant_ drivers modules will be "more and better"
than a (distro) kernel with _all_ drivers modules. That's the POINT of
modules -> be there or not, nothing else cares. If that's not the case
right now it's something we ought to fix first I'd say.
Of course there are other settings that do have impact (CPU type mostly,
maybe memory layout) but other than that... distros already ship several
binary versions (last I counted Red Hat ships 11 or so with RHL72) to
account for CPU type and amount etc.
Greetings,
Arjan van d Ven
Eric S. Raymond
> The goal of a typical end user is "make it work, make it go away and do what
> it did last week". Random mechanics hating car owners don't do engine tuning
> jobs or fit turbochargers.
No...but they do change their own oil and antifreeze. Upgrading your
kernel should be as simple as changing your oil.
> Secondly we've established we can pick the right CPU for the kernel reliably
> that is seperate to modules.
Right, but that doesn't get you a recompiled binary with extended instructions
in it.
> Thirdly building a lot of stuff modular is the right choice anyway - in the
> world of hot plugging and USB Grandma is not going to want to recompile her
> kernel because she bought a new trackball to boost her quake score.
I'm not arguing with building a lot of stuff modular. The autoconfiugurator
does exactly that for hot-plug buses.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"Are we to understand," asked the judge, "that you hold your own interests
above the interests of the public?"
"I hold that such a question can never arise except in a society of cannibals."
-- Ayn Rand
Alan Cox
> my system due to the way the Fathers of this operating system
> are taking it I will have no choice but to use another or be stuck
> at a non-maintained version . Now mind you I LIKE LINUX !
Right but you aren't going to go and use autoconfig except maybe to get
an initial Configuration to frob with ?
Alan
Alexander Viro
On Mon, 14 Jan 2002, David Lang wrote:
> I can see a couple reasons for building a kernel without useing modules.
>
> 1. security, if you don't need any modules you can disable modules entirly
> and then it's impossible to add a module without patching the kernel first
> (the module load system calls aren't there)
Oh, please... Give me permissions sufficient to make these syscalls
and in a couple of minutes your kernel will be replaced with ELIZA.
As a bonus - ELIZA running under TOPS-10 on PDP-10 emulator. And talking
to PARRY.
Anyway, it's trivial to disable said system calls just before doing
execve("/sbin/init",...). It won't buy you any security, but if you
insist...
> 2. speed, there was a discussion a few weeks ago pointing out that there
> is some overhead for useing modules (far calls need to be used just in
> case becouse the system can't know where the module will be located IIRC)
_That_ has to be addressed - regardless of anything else, if that suckitude
can be fixed it should be.
> 3. simplicity in building kernels for other machines. with a monolithic
> kernel you have one file to move (and a bootloader to run) with modules
> you have to move quite a few more files.
FVO"quite a few" equal to 2. Kernel and initramfs.cpio.gz
Ben Collins
> Alan Cox <al...@lxorguk.ukuu.org.uk>:
> > Now to do everything you describe does not need her to configure a custom
> > kernel tree. Not one bit. You think apt or up2date build each user a custom
> > kernel tree ?
>
> Is it OK in your world that Aunt Tillie is dependent on a distro maker? Is
> it OK that she never gets to have a kernel compiled for anything above the
> least-common-denominator chip?
>
> Not that I'm running down distro makers. They do a valuable job, and in fact
> my approach relies on Aunt Tillie's machine starting life with an all-modular
> distro kernel.
>
> But the point of this game is for Aunt Tillie to have more and better
> choices. Isn't that what we're supposed to be about?
Wouldn't it be better for Aunt Tillie to continue using an all modular
kernel (from a distro) so she doesn't have to "update" (in your example,
that means recompile) a new one everytime she adds new hardware? Does
she have to connect all of here 1394 and USB devices to the computer
during this phase in order to have them all supported?
Ben
--
.----------=======-=-======-=========-----------=====------------=-=-----.
/ Ben Collins -- Debian GNU/Linux \
` bcol...@debian.org -- bcol...@openldap.org -- bcol...@linux.com '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
Eli Carter
> Charles Cazabon <char...@discworld.dyndns.org>:
> > Yes, and yes. Aunt Tillie is running Linux because someone installed a
> > distribution for her.
>
> You don't know that. Maybe she installed it herself.
From a box she bought at CompUSA (or equiv.). She is dependant upon the
distro maker for the service they provide to her... that's what she's
paying them for.
> > She is never going to need anything out of her kernel that her vendor-shipped
> > update kernels do not provide.
>
> *You can't know that.*
>
> And your belief that you *can* know it is a key part of the elitist
> developer psychology and implicit assumptions that keeps Linux mostly
> inaccessible to the Aunt Tillies of the world.
Then she needs a better distribution, or at least one that caters to her
needs.
If there isn't such a distribution for her, she is no longer "Aunt
Tillie", but has become "Aun7 71LL13" ;)
Ahem, sorry, couldn't resist. :) I'll be quiet now.
Eli
--------------------. Real Users find the one combination of bizarre
Eli Carter \ input values that shuts down the system for days.
eli.carter(a)inet.com `-------------------------------------------------
Tom Rini
> > > it did last week". Random mechanics hating car owners don't do engine tuning
> > > jobs or fit turbochargers.
> >
> > No...but they do change their own oil and antifreeze. Upgrading your
> > kernel should be as simple as changing your oil.
>
> Yeah. I go to the garage versus I click "up 2 date". I don't mix custom
> oils.
And people that do change their own oil usually know something about
their cars too.
To carry this anaology out a bit further, the people who change their
own oil know about as much about their car(s) as the people who go and
recompile their own kernel, but don't claim to know much about the
kernel internals.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
Mr. James W. Laferriere
Hello All , And on that day linux will loose one small person .
Taf , JimL
On Mon, 14 Jan 2002, Eric S. Raymond wrote:
> Alan Cox <al...@lxorguk.ukuu.org.uk>:
> > For 2.5 if things go to plan there will be no such thing as a "compiled in"
> > driver. They simply are not needed with initramfs holding what were once the
> > "compiled in" modules.
>
> This is something of a bombshell. Not necessarily a bad one, but...
>
> Alan, do you have *any* *freakin'* *idea* how much more complicated
> the CML2 deduction engine had to be because the basic logical entity
> was a tristate rather than a bool? If this plan goes through, I'm
> going to be able to drop out at least 20% of the code, with most of
> that 20% being in the nasty complicated bits where the maintainability
> improvement will be greatest. And I can get rid of the nasty "vitality"
> flag, which probably the worst wart on the language.
>
> Yowza...so how soon is this supposed to happen?
> --
> <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
>
> Government should be weak, amateurish and ridiculous. At present, it
> fulfills only a third of the role. -- Edward Abbey
>
+------------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network Engineer | P.O. Box 854 | Give me Linux |
| bab...@baby-dragons.com | Coudersport PA 16915 | only on AXP |
+------------------------------------------------------------------+
-
Tom Rini
> Charles Cazabon <char...@discworld.dyndns.org>:
> > Yes, and yes. Aunt Tillie is running Linux because someone installed a
> > distribution for her.
>
> You don't know that. Maybe she installed it herself.
So she installed it herself, why isn't $distrovender kernel good enough?
Keep in mind that just because $kernelversion has a bug doesn't mean
that $distrovender-$kernelversion does. So yes, relying on an update
from $distrovendor is a good thing. What if your automagic tool existed
and Aunt Tillie clicked when 2.4.15 was current stable?
> > She is never going to need anything out of her kernel that her vendor-shipped
> > update kernels do not provide.
>
> *You can't know that.*
Would you accept She'll almost never need something thats not in her
current $distrovednor kernel or the one $distrovendor is working on?
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
Larry McVoy
> On Mon, Jan 14, 2002 at 12:52:28PM -0500, Eric S. Raymond wrote:
> > She complains of occasional lockups, and that she gets skips when
> > playing her Guy Lombardo MP3s. Melvin says, over the phone: "Yup,
> > that version had some VM problems. And you need the low-latency stuff
> > that went in three releases ago.
>
> ... and the 200 patches that the vendor added that she's become
> so used to just being there...
Yeah, what Dave said. Eric, your approach is pushing Aunt Tillie towards
more variations and what the Aunt Tillie needs is less. Ditto for the
distro vendors. They want as few as possible different kernels running
out there, the more variations there the greater the support load. It's
the *opposite* of what the Linux kernel community wants, they want the
broadest coverage of combinations they can get, that shows up more bugs.
If a distro vendor could get away with exactly one kernel config, they
would. Even if it made for a 20MB kernel image, the support tradeoff
is a win.
Supporting products for Aunt Tillie is very different than supporting
products for a bunch of hackers. One wants "it works" and the other
wants "the source".
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Dave Jones
> > She is never going to need anything out of her kernel that her vendor-shipped
> > update kernels do not provide.
> *You can't know that.*
> And your belief that you *can* know it is a key part of the elitist
> developer psychology and implicit assumptions that keeps Linux mostly
> inaccessible to the Aunt Tillies of the world.
nonsense. if theres some whizzy-new-feature that Aunt Tillie really
believes she'll need, there's more chance she'll find it in a
prepackaged tested vendor kernel than stock kernel. And if not,
then there's usually a good reason for non-inclusion.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
David Lang
> Date: Mon, 14 Jan 2002 19:17:46 +0000 (GMT)
> From: Alan Cox <al...@lxorguk.ukuu.org.uk>
> To: bab...@baby-dragons.com
> Cc: al...@lxorguk.ukuu.org.uk, linux-...@vger.kernel.org
> Subject: Re: Hardwired drivers are going away?
>
> > > Urban legend.
> > I do not agree . Got proof ? Yes that is a valid question .
>
> Most of the rootkit type stuff I see nowdays includes code for loading
> patches into module free kernels. Its a real no win. The better ones support
> regexp scanning so they can patch kernels where the sysadmin thinks he/she
> is cool and has hidden or crapped in System.map
>
> > > > case becouse the system can't know where the module will be located IIRC)
> > > I defy you to measure it on x86
> > OK ,How about sparc-64/alpha/ia64/... ?
>
> Not generally found in your grandmothers PC
doesn't matter, they are likly to be found on dedicated servers where
the flexibility of modules is not needed and the slight performance
advantage is desired.
making everything modular is fine for desktops/laptops but why should
dedicated servers pay the price?
> > > > 3. simplicity in building kernels for other machines. with a monolithic
> > > > kernel you have one file to move (and a bootloader to run) with modules
> > > > you have to move quite a few more files.
> > > tar or nfs mount; make modules_install.
> > Please my laugh'o meter is stuck already . Sorry . JimL
>
> Then fix it, because the above works well. Also remember that autoconfig
> tools won't be able to guess remote machines very well 8)
I don't want autoconfig to detect my remote machines I want to specify
them directly. (there are likly to be things on the motherboards of
machines that I don't want to compile into the kernel, sound cards for
servers are one example, video drivers are another, and USB is a third)
autoconfig is supposed to be an option, not the only way to compile a
kernel (or are you saying that you don't want to be able to use your 1.2G
athlon to build the kernel for your 486?)
David Lang
David Lang
everything to be modules.
autoconfig is a useful tool in some cases, but is not going to be used
everywhere.
I view modules as being in the same catagory.
David Lang
On Mon, 14 Jan 2002, Alan Cox wrote:
> Date: Mon, 14 Jan 2002 19:17:46 +0000 (GMT)
> From: Alan Cox <al...@lxorguk.ukuu.org.uk>
> To: bab...@baby-dragons.com
> Cc: al...@lxorguk.ukuu.org.uk, linux-...@vger.kernel.org
> Subject: Re: Hardwired drivers are going away?
>
Charles Cazabon
> Charles Cazabon <char...@discworld.dyndns.org>:
> > Yes, and yes. Aunt Tillie is running Linux because someone installed a
> > distribution for her.
>
> You don't know that. Maybe she installed it herself.
If she installed Linux herself, today, then she's not Aunt Tillie. She's "my
Aunt Tillie who's something of a computer hobbyist, and not afraid to install
a Unix-like OS on her PC alongside (or instead of) Windows". That's a _whole_
different ballgame -- and if she can do that, then she's fully capable of
reading a little bit and answering some yes/no questions to compile a kernel.
> > She is never going to need anything out of her kernel that her
> > vendor-shipped update kernels do not provide.
>
> *You can't know that.*
Sure I can -- the same way I know that Ma & Pa Kettle are never going to use
their computer for more than email, web surfing, and playing Solitaire.
> And your belief that you *can* know it is a key part of the elitist
> developer psychology and implicit assumptions that keeps Linux mostly
> inaccessible to the Aunt Tillies of the world.
No, my beliefs are based on twenty years of observing people using computers
and technoogy. I have yet to see a single person who is simultaneously (i)
technical enough to need something from their kernel that their distribution
vendor doesn't provide, and (ii) not technical enough to be able to compile it
themselves with today's tools.
I think your auto-configurator will be something of a white elephant --
equivalent to a better guide for setting the clock in your VCR. Those people
who can't figure out how to set their VCR clock from the current instructions
are the same people who don't care whether it flashes "12:00" or not.
Charles
--
-----------------------------------------------------------------------
Charles Cazabon <li...@discworld.dyndns.org>
GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/
-----------------------------------------------------------------------
Eric S. Raymond
> Of course there are other settings that do have impact (CPU type mostly,
> maybe memory layout) but other than that... distros already ship several
> binary versions (last I counted Red Hat ships 11 or so with RHL72) to
> account for CPU type and amount etc.
OK. Scenario #2:
Tillie's nephew Melvin is a junior-grade geek. He's working his way
through college doing website administration for small businesses. He
doesn't know C, but he can hack his way around Perl and a little PHP,
and he can type "configure; make". He's been known to wear a penguin
T-shirt.
Some time back he set up a Linux box for Joe Foonly over at Joe's
Garage. Joe calls him back and says "Hey, kid, I gotta problem here.
Lot of hits on that website and the machine's getting sluggish when
I'm doing my books with GnuCash on it at the same time. But what with
the recession and all, I don't want to go buying new hardware if I can
help it."
Melvin thinks to himself "OK, let's see if we can't tune this sucker a
bit." He runs top(1) and sees a bad shortage of free RAM; the box is
an older machine, a 586-based PCI/ISA hybrid from around 1995, and
only has 32MiB of memory in it. But Joe doesn't want to spend money
on hardware and, since money is tight all over and Joe took care of
the state inspection for Melvin's car a few weeks ago without getting
around to billing him yet, Melvin kind of needs to make the best of
the situation.
Melvin thinks this is no problem, he'll start by building a new kernel
with some stuff trimmed out to leave more RAM for userspace. But...
uh oh! He nuked that source tree because free disk was getting kind
of tight, and the .config went with it. Looks like Melvin's going to
have to reconstruct his configuration by hand.
"Crap." Melvin thinks. "I don't remember what kind of network card I
compiled in. Am I going to have to open this puppy up just to eyeball
the hardware?" Doing that would take time Melvin was planning to spend
chatting up a girl geek he's noticed over at the computer lab.
Autoconfigure saves the day. Possibly it even helps Melvin get laid.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Freedom, morality, and the human dignity of the individual consists
precisely in this; that he does good not because he is forced to do
so, but because he freely conceives it, wants it, and loves it.
-- Mikhail Bakunin
Alexander Viro
On Mon, 14 Jan 2002, David Lang wrote:
> doesn't matter, they are likly to be found on dedicated servers where
> the flexibility of modules is not needed and the slight performance
> advantage is desired.
>
> making everything modular is fine for desktops/laptops but why should
> dedicated servers pay the price?
There should be no price. And AFAICS that's doable.
> autoconfig is supposed to be an option, not the only way to compile a
> kernel (or are you saying that you don't want to be able to use your 1.2G
> athlon to build the kernel for your 486?)
autoconfig is completely separate story. There are very good reasons to
avoid built-in/modular crap, regardless of the autoconf. Every #ifdef MODULE
is a bug waiting to happen - simply because the stuff gets out of sync.
Every place that consists of
#ifdef CONFIG_FOO
init_foo();
#endif
....
is a permanent source of PITA for out-of-tree drivers/patch merging/etc.
And that's aside of the fun with ordering, etc.
If we can get rid of performance hit on modular code - we should go
for that variant simply because it reduces the amount of bug sources.
Autoconfig and other details of ESR's Aunt Tillie fetish belong to
alt.sex.* - from time to time they may be amusing, but let's not
mix them with the technical arguments, OK?
Charles Cazabon
> > Of course there are other settings that do have impact (CPU type mostly,
> > maybe memory layout) but other than that... distros already ship several
> > binary versions (last I counted Red Hat ships 11 or so with RHL72) to
> > account for CPU type and amount etc.
>
> OK. Scenario #2:
Hmm. This scenario seems totally bogus.
[...]
> Some time back he set up a Linux box for Joe Foonly over at Joe's
> Garage. Joe calls him back and says "Hey, kid, I gotta problem here.
> Lot of hits on that website and the machine's getting sluggish when
> I'm doing my books with GnuCash on it at the same time.
[...]
> the box is
> an older machine, a 586-based PCI/ISA hybrid from around 1995, and
> only has 32MiB of memory in it.
[...]
Hmmm, 32MiB of RAM on a 586-class machine, and its doing useful work as both a
webserver and running GnuCash? Care to construct something more real-world?
Even at that:
> Melvin thinks this is no problem, he'll start by building a new kernel
> with some stuff trimmed out to leave more RAM for userspace. But...
> uh oh! He nuked that source tree because free disk was getting kind
> of tight, and the .config went with it. Looks like Melvin's going to
> have to reconstruct his configuration by hand.
>
> "Crap." Melvin thinks. "I don't remember what kind of network card I
> compiled in. Am I going to have to open this puppy up just to eyeball
> the hardware?"
Uh, no. Try `lsmod`.
> Autoconfigure saves the day.
Autoconfigure not necessary; read the output of lsmod, or read modules.conf.
Problem solved.
Charles
--
-----------------------------------------------------------------------
Charles Cazabon <li...@discworld.dyndns.org>
GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/
-----------------------------------------------------------------------
Mr. James W. Laferriere
Hello Alan ,
On Mon, 14 Jan 2002, Alan Cox wrote:
> > No, But it is -mine- ! If I can not have complete control over
> > my system due to the way the Fathers of this operating system
> > are taking it I will have no choice but to use another or be stuck
> > at a non-maintained version . Now mind you I LIKE LINUX !
> Right but you aren't going to go and use autoconfig except maybe to get
> an initial Configuration to frob with ?
Ok , Now I am confused . I guess it's not hard to do .
Is the Kernel headed toward Soft drivers or not ?
I get my initial Config (say from autoconf.) how will that keep
the Drivers in the Kernel ? Tia , JimL
+------------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network Engineer | P.O. Box 854 | Give me Linux |
| bab...@baby-dragons.com | Coudersport PA 16915 | only on AXP |
+------------------------------------------------------------------+
-
gm...@innerfire.net
> Date: Mon, 14 Jan 2002 14:50:35 -0500
> From: Eric S. Raymond <e...@thyrsus.com>
> To: ar...@fenrus.demon.nl
> Cc: linux-...@vger.kernel.org
> Subject: Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery
> -- the elegant solution)
> "Crap." Melvin thinks. "I don't remember what kind of network card I
> compiled in. Am I going to have to open this puppy up just to eyeball
> the hardware?" Doing that would take time Melvin was planning to spend
> chatting up a girl geek he's noticed over at the computer lab.
BTDT queried the current kernel for the info I needed.
ISA doesn't look like it was designed to be autodetected at least not the
really old stuff.. if it's on a 586 it's likely to be at least PnP and
therefore more easilly detectable.
IMO ISA was designed for techies and not for J Random User.
--
Gerhard Mack
<>< As a computer I find your faith in technology amusing.
Justin Carlson
will find) an autoconfigurator useful in my work, if only to get a
rough-cut kernel configuration done in minimal time. For my purposes,
it doesn't have to be 100% correct to save me some significant amount of
work.
Does this mean I'm incapable of configuring a kernel with the available
tools? No. And it doesn't mean I think there needs to be some grand
shift in the way distro vendors provide kernels, but this kind of a
facility would be useful for *me*. I don't want to get into whether
this is an appropriate thing to make easily accessible to good ol' Aunt
Tillie.
From the other side, how does having the ability to probe local hardware
hurt? It should be cleanly seperable from the classical build process
for the purists, and helpful to some (I think) significant portion of
the userbase, particularly those folks who like to test bleeding edge
stuff on a variety of hardware. I don't really understand the
resistance to the idea of someone going out and implementing this.
my $.02.
-Justin
Eric S. Raymond
> > "Crap." Melvin thinks. "I don't remember what kind of network card I
> > compiled in. Am I going to have to open this puppy up just to eyeball
> > the hardware?"
>
> Uh, no. Try `lsmod`.
He hard-compiled in that driver. lsmod(1) can't see it.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
No one is bound to obey an unconstitutional law and no courts are bound
to enforce it. -- 16 Am. Jur. Sec. 177 late 2d, Sec 256
Dave Jones
> "Crap." Melvin thinks. "I don't remember what kind of network card I
> compiled in. Am I going to have to open this puppy up just to eyeball
> the hardware?" Doing that would take time Melvin was planning to spend
> chatting up a girl geek he's noticed over at the computer lab.
> Autoconfigure saves the day. Possibly it even helps Melvin get laid.
Unless of course, geekgirl realises what a dork Melvin was for
not doing something like lsmod / looking in /var/log/messages for
boot messages showing not only what card he has, but what driver
he needs.
Common sense saves the day. Possibly it even saves Melvin making an ass
of himself. 8-)
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
Eric S. Raymond
> But it still leaves you with tristate - instead of yes/module/no it's
> yes/yes, but don't put it on initramfs/no. However, dependencies become
> simpler - all you need is "I want this, that and that on initramfs" and
> the rest can be found by depmod (i.e. configurator doesn't have to deal
> with "FOO goes on initramfs (== old Y), so BAR and BAZ must go there
> (== can't be M)").
Actually I think we may no longer be in tristate-land. Instead, some
devices have the property "This belongs in initramfs if it's configured
at all" -- specifically, drivers for potential boot devices. Everything
else can dynamic-load after boot time.
In CML2 you can assign a symbol properties, which are written into
trailing comments in the config file on the same line as the symbol
value assignment. One such property, "PRIVATE", is already
interpreted by the postprocessor that generates autoconf.h from the
configuration output; it prevents the symbol from being written to
autoconf.h.
The critical-for-boot property could be interpreted by the same
postprocessor script and turned into a manifest for initramfs. There
would be no need for the inference engine or configurator to know
about this property at all, just as it doesn't need to know anything
about PRIVATE.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"To disarm the people... was the best and most effectual way to enslave them."
-- George Mason, speech of June 14, 1788
Chris Friesen
>
> On Mon, 14 Jan 2002, David Lang wrote:
>
> > doesn't matter, they are likly to be found on dedicated servers where
> > the flexibility of modules is not needed and the slight performance
> > advantage is desired.
> >
> > making everything modular is fine for desktops/laptops but why should
> > dedicated servers pay the price?
>
> There should be no price. And AFAICS that's doable.
I haven't been following the initramfs stuff, but now I have a question.
Currently we're using initrd to store a kernel and compressed ramdisk bundled
together as an ~7MB single file that gets netbooted by firmware in a card. Will
it be possible to bundle initramfs together with the kernel into a single file
in this same manner?
Thanks,
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: cfri...@nortelnetworks.com
Dave Jones
> > > compiled in. Am I going to have to open this puppy up just to eyeball
> > > the hardware?"
> > Uh, no. Try `lsmod`.
> He hard-compiled in that driver. lsmod(1) can't see it.
$ grep eth0 /var/log/boot.msg
<6>eth0: PCnet/FAST+ 79C972 at 0x9400, 00 a0 d2 18 c0 2c
(Ok, it's not ISA, but it serves a point).
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
Henrique de Moraes Holschuh
> On Mon, Jan 14, 2002 at 07:38:24PM +0100, Dave Jones wrote:
> If a distro vendor could get away with exactly one kernel config, they
> would. Even if it made for a 20MB kernel image, the support tradeoff
> is a win.
Looks like Debian's look-mama-I-can-beat-godzila-hands-down 2.4 kernel
packages with everything AND the kitchen sink... :) They eat about 20Mb of
diskspace, I think.
Package: kernel-image-2.4.16-k7
Installed-Size: 22976
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
David Lang
that can be bypassed, but as long as it's not your only security it's
still worth doing)
also with hardwired drivers going away does this mean that other things
that are currently compiled in will become modules, like say the IP stack?
David Lang
On Mon, 14 Jan 2002, Eric S. Raymond wrote:
> Date: Mon, 14 Jan 2002 15:17:48 -0500
> From: Eric S. Raymond <e...@thyrsus.com>
> To: Alexander Viro <vi...@math.psu.edu>
> Cc: Alan Cox <al...@lxorguk.ukuu.org.uk>,
> Mr. James W. Laferriere <bab...@baby-dragons.com>,
> Giacomo Catenazzi <ca...@debian.org>,
> Linux Kernel List <linux-...@vger.kernel.org>
> Subject: Re: Hardwired drivers are going away?
>
Eric S. Raymond
> On Mon, Jan 14, 2002 at 02:50:35PM -0500, Eric S. Raymond wrote:
> > "Crap." Melvin thinks. "I don't remember what kind of network card I
> > compiled in. Am I going to have to open this puppy up just to eyeball
> > the hardware?" Doing that would take time Melvin was planning to spend
> > chatting up a girl geek he's noticed over at the computer lab.
> > Autoconfigure saves the day. Possibly it even helps Melvin get laid.
>
> Unless of course, geekgirl realises what a dork Melvin was for
> not doing something like lsmod / looking in /var/log/messages for
> boot messages showing not only what card he has, but what driver
> he needs.
Right now, neither lsmod nor the boot time messages necessarily give you that
information. lsmod only works if the driver is in fact a module. My
/var/log/dmesg contains no message from the NIC on my motherboard. And
going from the driver to the config symbol isn't trivial even if you *have*
the lsmod or dmesg information.
And anyway there are settings you can't even recover by looking at the
hardware, such as whether KHTTPD or BSD process accounting were turned
on.
Sure, Melvin could remember a whole bunch of state, or a whole bunch
of rules for reconstructing it. But isn't sweating that kind of detail
exactly what *computers* are for?
Melvin, you may be sure, has more important things on his mind...
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
That the said Constitution shall never be construed to authorize
Congress to infringe the just liberty of the press or the rights of
conscience; or to prevent the people of the United states who are
peaceable citizens from keeping their own arms...
-- Samuel Adams, in "Phila. Independent Gazetteer", August 20, 1789
Alexander Viro
On Mon, 14 Jan 2002, Chris Friesen wrote:
> I haven't been following the initramfs stuff, but now I have a question.
> Currently we're using initrd to store a kernel and compressed ramdisk bundled
> together as an ~7MB single file that gets netbooted by firmware in a card. Will
> it be possible to bundle initramfs together with the kernel into a single file
> in this same manner?
<shrug> kernel unpacks to rootfs after init_vfs_caches(). It does
populate_root(archive_start, archive_size);
followed by releasing that area. That's it. If you have these variables
set - it will work, no matter how did the archive get there.
Brian Gerst
>
> Charles Cazabon <li...@discworld.dyndns.org>:
> > > "Crap." Melvin thinks. "I don't remember what kind of network card I
> > > compiled in. Am I going to have to open this puppy up just to eyeball
> > > the hardware?"
> >
> > Uh, no. Try `lsmod`.
>
> He hard-compiled in that driver. lsmod(1) can't see it.
cat /proc/ioports. If the card is in use, it will show up there.
--
Brian Gerst
Hugh Dickins
>
> Tillie's nephew Melvin is a junior-grade geek. He's working his way
> Some time back he set up a Linux box for Joe Foonly over at Joe's
> Garage. Joe calls him back and says "Hey, kid, I gotta problem here.
> Autoconfigure saves the day. Possibly it even helps Melvin get laid.
> so, but because he freely conceives it, wants it, and loves it.
This is terrific stuff! "The Bold & the Bazaarre"?
Hugh
Alan Cox
> compiled in. Am I going to have to open this puppy up just to eyeball
> the hardware?" Doing that would take time Melvin was planning to spend
So he builds a kernel with modular setups just like the vendor kernel. The
existing module configuration and setup data that worked with the old
kernel keeps working and he has time to read up on his technique and get
laid.
I just don't buy your examples. Eric all I can think is that you have seriously
weird relatives.
Alan
Ian Molton
sheaf of electrons and etched in their motions the following immortal
words:
> doesn't matter, they are likly to be found on dedicated servers where
> the flexibility of modules is not needed and the slight performance
> advantage is desired.
Exactly WHAT performance advantage? once the module is loaded, its loaded.
most modules use the same code to handle modular and non-modular builds
anyhow (look at the ide drivers, for example)
Dave Jones
> Right now, neither lsmod nor the boot time messages necessarily give you that
> information.
One of the great things about Linux (or at least I think so) kernel
is it's incredibly verbose startup.
If you have a configured network, boot messages WILL tell you
what driver is controlling that card. If built as a module
lsmod WILL tell you.
> /var/log/dmesg contains no message from the NIC on my motherboard.
Then that's a driver issue. What NIC ?
> And going from the driver to the config symbol isn't trivial even
> if you *have* the lsmod or dmesg information.
Then we need better descriptions in the CML2 rules.
> And anyway there are settings you can't even recover by looking at the
> hardware, such as whether KHTTPD or BSD process accounting were turned
> on.
ls /proc/sys/net/khttpd
ls /proc/sys/kernel/acct
> Sure, Melvin could remember a whole bunch of state, or a whole bunch
> of rules for reconstructing it. But isn't sweating that kind of detail
> exactly what *computers* are for?
If Melvin really does have a mind like a sieve,he'd put .config
somewhere sensible after building a kernel.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
-
Alan Cox
> > > compiled in. Am I going to have to open this puppy up just to eyeball
> > > the hardware?"
> >
> > Uh, no. Try `lsmod`.
>
> He hard-compiled in that driver. lsmod(1) can't see it.
You mean he broke the carefully designed vendor set up by running a poorly
designed autoconfig script ? See if he'd run a sensible modular one he would
be fine
Jeff Garzik
> Right now, neither lsmod nor the boot time messages necessarily give you that
> information. lsmod only works if the driver is in fact a module. My
> /var/log/dmesg contains no message from the NIC on my motherboard. And
> going from the driver to the config symbol isn't trivial even if you *have*
> the lsmod or dmesg information.
For network cards one needs only to issue the ETHTOOL_GDRVINFO ioctl to
find out what hardware is associated with an ethernet interface.
Jeff
--
Jeff Garzik | Alternate titles for LOTR:
Building 1024 | Fast Times at Uruk-Hai
MandrakeSoft | The Took, the Elf, His Daughter and Her Lover
| Samwise Gamgee: International Hobbit of Mystery
David Lang
near calls each and every call is (a hair) slower.
so the code can be the same and still be slower to get to.
you can argue that it's not enough slower to matter, but even Alan admits
there is some impact.
David Lang
On Mon, 14 Jan 2002, Ian Molton wrote:
> Date: Mon, 14 Jan 2002 20:51:24 +0000
> From: Ian Molton <sp...@armlinux.org>
> To: linux-...@vger.kernel.org
> Subject: Re: Hardwired drivers are going away?
>
Dave Jones
>
> For network cards one needs only to issue the ETHTOOL_GDRVINFO ioctl to
> find out what hardware is associated with an ethernet interface.
but not all the net drivers support this yet do they?
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
Oliver Xymoron
> Alexander Viro <vi...@math.psu.edu>:
> > But it still leaves you with tristate - instead of yes/module/no it's
> > yes/yes, but don't put it on initramfs/no. However, dependencies become
> > simpler - all you need is "I want this, that and that on initramfs" and
> > the rest can be found by depmod (i.e. configurator doesn't have to deal
> > with "FOO goes on initramfs (== old Y), so BAR and BAZ must go there
> > (== can't be M)").
>
> Actually I think we may no longer be in tristate-land. Instead, some
> devices have the property "This belongs in initramfs if it's configured
> at all" -- specifically, drivers for potential boot devices. Everything
> else can dynamic-load after boot time.
The knowledge of what's required to boot can and should be moved out of
the kernel to distro land. 'make install' should call the distro's install
script that sez /boot and /lib are on ext3 on /dev/sd?, ergo I need to
include the ext3 and relevant SCSI modules.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
Reid Hekman
> Right now, neither lsmod nor the boot time messages necessarily give you that
> information. lsmod only works if the driver is in fact a module. My
> /var/log/dmesg contains no message from the NIC on my motherboard. And
> going from the driver to the config symbol isn't trivial even if you *have*
> the lsmod or dmesg information.
Yes, getting the current used environment from the running kernel in a
simple way would be nice. Actually, I'm interested in trying out your
autoconfigurator, though I'll be one to go back to the config and look
it over. The Aunt Tillie scenario doesn't preclude the usefulness of an
autoconfig tool.
> Sure, Melvin could remember a whole bunch of state, or a whole bunch
> of rules for reconstructing it. But isn't sweating that kind of detail
> exactly what *computers* are for?
Precisely. The Real Problem(TM) is there are more issues than initial
kernel configuration that effect the details the user installing a
kernel or device is required to know. For a real example of this -- Grip
fails to see an audio CD in my CDRW when ide-scsi is loaded, DVD
playback is also slower but I need ide-scsi so I can backup CD's from
one drive to another. Right now, if I want to do one or another task, I
need to reboot using different kernel command lines, with a script to
alter my /dev links so the relevant apps continue to work. For another,
some of my apps need to be poked and prodded when my USB webcam hops
from /dev/video1 to /dev/video0 depending on whether bttv was or not.
Fixing those bits will allow vendors to make better and easier choices
with supplied kernels, at which point initial kernel (auto)configuration
becomes less important. I guess it's part of what Linus calls growing to
have a "middle-aged" kernel.
Anyway, I know it's not a zero sum game. We can't make Eric stop work on
one thing and make him do another. In what ways could an
autoconfigurator better work in today's environment? What could the
kernel do to make that job easier while not offending people too much?
Regards,
Reid
Chris Adams
>I can see a couple reasons for building a kernel without useing modules.
>
>1. security, if you don't need any modules you can disable modules entirly
>and then it's impossible to add a module without patching the kernel first
>(the module load system calls aren't there)
There is no security gain from disabling module loading. If someone has
the level of access needed to load modules, they also have access to
/dev/mem. Run-time patching of the kernel is something that can be done
(and probably is done by some rootkits). For bonus points, patch in the
system call(s) required by insmod and voila: module loading now works
(instead of having to patch all your rootkit code into the running
kernel, patch in insmod and let the kernel load the code for you).
--
Chris Adams <cma...@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
Eric S. Raymond
> > "Crap." Melvin thinks. "I don't remember what kind of network card I
> > compiled in. Am I going to have to open this puppy up just to eyeball
> > the hardware?" Doing that would take time Melvin was planning to spend
>
> So he builds a kernel with modular setups just like the vendor kernel. The
> existing module configuration and setup data that worked with the old
> kernel keeps working and he has time to read up on his technique and get
> laid.
Where did your assumption that Melvin has the canned config files to
do that still available come from? More fundamentally: which should
he *have* to have those configs available?
> I just don't buy your examples. Eric all I can think is that you
> have seriously weird relatives.
Correct. My relatives are *much* weirder than Melvin and Tillie :-).
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Faith may be defined briefly as an illogical belief in the occurrence
of the improbable...A man full of faith is simply one who has lost (or
never had) the capacity for clear and realistic thought. He is not a
mere ass: he is actually ill. -- H. L. Mencken
Greg KH
>
> The klibc source/binary debate still seems to be ongoing, but apart from
> that, will the build process for initramfs be part of the kernel build or not?
I would vote for yes. I would like this, if for no other reason than
the number of kernel builds most kernel developers do :)
I was going to wait until kbuild 2.5 went into the tree before looking
at what would be needed to add this to the build process.
thanks,
greg k-h
Jeff Garzik
>
> On Mon, Jan 14, 2002 at 05:07:37PM -0500, Jeff Garzik wrote:
> >
> > For network cards one needs only to issue the ETHTOOL_GDRVINFO ioctl to
> > find out what hardware is associated with an ethernet interface.
>
> but not all the net drivers support this yet do they?
correct. But it is the proper path one should take on this particular
train of thought ;-)
--
Jeff Garzik | Alternate titles for LOTR:
Building 1024 | Fast Times at Uruk-Hai
MandrakeSoft | The Took, the Elf, His Daughter and Her Lover
| Samwise Gamgee: International Hobbit of Mystery
Tom Gilbert
> Alan Cox <al...@lxorguk.ukuu.org.uk>:
> > Now to do everything you describe does not need her to configure a custom
> > kernel tree. Not one bit. You think apt or up2date build each user a custom
> > kernel tree ?
>
> Is it OK in your world that Aunt Tillie is dependent on a distro maker? Is
> it OK that she never gets to have a kernel compiled for anything above the
> least-common-denominator chip?
$ apt-cache search kernel-image | grep 2.4.17
kernel-image-2.4.17-386 - Linux kernel image for version 2.4.17 on 386.
kernel-image-2.4.17-586tsc - Linux kernel image for version 2.4.17 on
Pentium-Classic.
kernel-image-2.4.17-686 - Linux kernel image for version 2.4.17 on
PPro/Celeron/PII/PIII.
kernel-image-2.4.17-686-smp - Linux kernel image 2.4.17 on
PPro/Celeron/PII/PIII SMP.
kernel-image-2.4.17-k6 - Linux kernel image for version 2.4.17 on AMD
K6/K6-II/K6-III
kernel-image-2.4.17-k7 - Linux kernel image for version 2.4.17 on AMD K7
pcmcia-modules-2.4.17-386 - PCMCIA Modules for Linux (kernel
2.4.17-386).
Aunt Tillie's distro autodetects her processor type and installs the
appropriate image. Aunt Tillie's distro provides precompiled,
preconfigured, modular kernels which require no configuration. Aunt
Tillie clicks on the "check for software updates" icon on her desktop
and her distro installs security fixes, new software, and a new kernel.
Aunt Tillie doesn't even have to _know_ she needs a better VM.
> But the point of this game is for Aunt Tillie to have more and better
> choices. Isn't that what we're supposed to be about?
$ apt-cache search kernel-image | wc -l
49
Tom.
--
.^. .-------------------------------------------------------.
/V\ | Tom Gilbert, London, England | http://linuxbrit.co.uk |
/( )\ | Open Source/UNIX consultant | t...@linuxbrit.co.uk |
^^-^^ `-------------------------------------------------------'
Eric S. Raymond
> Make autoconfigure expands the pool of people who can build kernels,
> but it's not going to saturate the populace to the point where
> everybody immediately SHOULD. Not even close. Over time, the pool
> will grow. But aiming for Aunt Tillie in the short term is probably
> overreaching.
No, it's not. Because the second we stop thinking about Aunt Tillie,
we start making excuses for badly-designed interfaces and excessive
complexity. We tend to fall back into insular, elitist assumptions
that limit both the useability of our software and its potential user
population. We get lazy and stop checking our assumptions. When we
do this, Bill Gates laughs at us, and is right to do so.
I've seen it happen in this thread. Many lkml people clearly have the
attitude that if you aren't willing to sweat the arcana, you
shouldn't be building kernels. Whst they don't realize is that with
that attitude, we not only lose the Aunt Tillies of the world, we
inflict a lot of unnecessary hassle on *ourselves*, too. We're
sweating details with think time we could be spending creatively.
Therefore I try to stay focused on Aunt Tillie even though I know
that you are objectively correct and her class of user is likely
not to build kernels regularly for some years yet.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
No matter how one approaches the figures, one is forced to the rather
startling conclusion that the use of firearms in crime was very much
less when there were no controls of any sort and when anyone,
convicted criminal or lunatic, could buy any type of firearm without
restriction. Half a century of strict controls on pistols has ended,
perversely, with a far greater use of this weapon in crime than ever
before.
-- Colin Greenwood, in the study "Firearms Control", 1972
Alan Cox
> do that still available come from? More fundamentally: which should
> he *have* to have those configs available?
Because the GPL says he's entitled to them ?
Eric S. Raymond
> > Where did your assumption that Melvin has the canned config files to
> > do that still available come from? More fundamentally: which should
> > he *have* to have those configs available?
>
> Because the GPL says he's entitled to them ?
You miss my point. Sure he's entitled to them. But why should he
*have to have them*? They're extra state which, in the presence
of a proper autoconfigurator, he doesn't need.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Militias, when properly formed, are in fact the people themselves and
include all men capable of bearing arms. [...] To preserve liberty it is
essential that the whole body of the people always possess arms and be
taught alike, especially when young, how to use them.
-- Senator Richard Henry Lee, 1788, on "militia" in the 2nd Amendment
Bruce Harada
"Eric S. Raymond" <e...@thyrsus.com> wrote:
> Therefore I try to stay focused on Aunt Tillie even though I know
> that you are objectively correct and her class of user is likely
> not to build kernels regularly for some years yet.
Change that last line to read "her class of user will never build kernels ever,
and would be aggressively disinterested in the possibility of doing so", and
you might be closer to the truth.
Aunt Tillie just DOESN'T CARE, OK? She can talk to her vendor if she gets
worried about whether her kernel supports the Flangelistic2000 SuperDoodad.
Tom Gilbert
> > > Doesn't this mean that you would need a fully functional kernel
> > > before you get to run the autoconfigurator?
> >
> > Yes, but this was always true.
>
> No it's not. You only need a kernel that can run your compiler.
It's already been pointed out that the autconfigurator requires a great
many in-kernel features and userspace utilities.
Tom.
--
.^. .-------------------------------------------------------.
/V\ | Tom Gilbert, London, England | http://linuxbrit.co.uk |
/( )\ | Open Source/UNIX consultant | t...@linuxbrit.co.uk |
^^-^^ `-------------------------------------------------------'
Rusty Russell
Alexander Viro <vi...@math.psu.edu> wrote:
> Two technical obstacles:
> a) on some architecures modular code is slower (IIRC, the problem is
> with medium-range calls being faster than far ones and usable only in the
> kernel proper). We probaly want to leave a gap after the .text and remap
> .text of module in there - if I understand the problem that should be
> enough, but that's really a question to folks dealing with these ports (PPC64
> and Itanic?)
Sparc64 has a special allocator. PPC32 is not so lucky, and if the module
doesn't end up under 32MB we use trampolines (PLT in the ppc parlance).
PPC64 has similar issues.
> b) current differences between options parsing in case of built-in
> and modular drivers.
I have a patch for this, of course, but it's tied to my replacement module
loader:
http://www.kernel.org/pub/linux/kernel/people/rusty/patches/Module/param.patch.bz2
Cheers!
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.