while i read a recent post stating, essentially, "it's unlikely
that the overall hierarchy of the config screens is going to
change much," i find the 2.5 layout pretty much as confusing
and illogical as the 2.4 screens. some petty and not-so-petty
examples and suggestions:
Loadable module support
Does "Module unloading" mean whether or not I can run "rmmod"?
And if I deselect this, why can I still select "Forced module
unloading"? Either I can unload or I can't, no?
And what's the rationale behind making unloading an option,
anyway? If I want loadable module support, is it really a
big deal to assume I'll want the ability to unload them as
well? Just curious, that's all. Under what circumstances
would I explicitly *not* want the ability to rmmod? Tight
space embedded kernels, possibly?
Processor family
It seems that the final option, "Preemptible kernel", does
not belong there. In fact, there seem to be a number of
kernel-related, kind of hacking/debugging options, that
could be collected in one place, like preemption, sysctl,
hacking, executable file formats, etc. "Low-level kernel
options", perhaps?
Bus options (PCI, PCMCIA, EISA, MCA, ISA)
First, there's no hint from that heading that hot-pluggable
settings are hidden under there as well.
In addition, why does "Bus options" not include the USB bus,
the I2C bus, FireWire, etc? A bus is a bus, isn't it?
Multimedia devices
How come "Sound" is not here? And (as we've already
established), Radio Adapters is not a sub-entry of Video for
Linux. :-) (And is there a reason why Amateur Radio Support
and Radio Adapters are so far apart in the config menus?
Wireless networking/protocols
Yes, I realize there's no such category, but there *should*
be, which would include:
Wireless LAN (non ham-radio)
Bluetooth
IrDA
anyway, just some observations from someone who doesn't
know any better.
rday
> Does "Module unloading" mean whether or not I can run "rmmod"?
> And if I deselect this, why can I still select "Forced module
> unloading"? Either I can unload or I can't, no?
>
> And what's the rationale behind making unloading an option,
> anyway? If I want loadable module support, is it really a
> big deal to assume I'll want the ability to unload them as
> well? Just curious, that's all. Under what circumstances
> would I explicitly *not* want the ability to rmmod? Tight
> space embedded kernels, possibly?
These two are for Rusty to answer.
> It seems that the final option, "Preemptible kernel", does
> not belong there. In fact, there seem to be a number of
> kernel-related, kind of hacking/debugging options, that
> could be collected in one place, like preemption, sysctl,
> hacking, executable file formats, etc. "Low-level kernel
> options", perhaps?
Should go to "General config" IMHO.
> Bus options (PCI, PCMCIA, EISA, MCA, ISA)
>
> First, there's no hint from that heading that hot-pluggable
> settings are hidden under there as well.
Well, PCMCIA pretty much suggests that, doesn't it?
> In addition, why does "Bus options" not include the USB bus,
> the I2C bus, FireWire, etc? A bus is a bus, isn't it?
Yes, this is a valid comment. Placing USB under "Bus options"
should be totally straightforward, but that one's for Greg KH
to decide.
> Multimedia devices
>
> How come "Sound" is not here? And (as we've already
> established), Radio Adapters is not a sub-entry of Video for
> Linux. :-) (And is there a reason why Amateur Radio Support
> and Radio Adapters are so far apart in the config menus?
Yeah, this one is a puzzle. <g>
> Wireless networking/protocols
>
> Yes, I realize there's no such category, but there *should*
> be, which would include:
>
> Wireless LAN (non ham-radio)
> Bluetooth
> IrDA
IrDA isn't necessarily networking, Bluetooth either.
Wireless LAN is where it should be.
> anyway, just some observations from someone who doesn't
> know any better.
Thanks.
--
Tomas Szepe <[email protected]>
On Wed, 1 Jan 2003, Tomas Szepe wrote:
> > Bus options (PCI, PCMCIA, EISA, MCA, ISA)
> >
> > First, there's no hint from that heading that hot-pluggable
> > settings are hidden under there as well.
>
> Well, PCMCIA pretty much suggests that, doesn't it?
you're right, based on the menus as they are now. however,
as i think more about it, if you consider the next comment ...
>
> > In addition, why does "Bus options" not include the USB bus,
> > the I2C bus, FireWire, etc? A bus is a bus, isn't it?
>
> Yes, this is a valid comment. Placing USB under "Bus options"
> should be totally straightforward, but that one's for Greg KH
> to decide.
what might have been gnawing at me was, if USB (and other busses)
are added here as well, then *most* hotplug options would be in
one place. just one way of looking at it.
> > Wireless networking/protocols
> >
> > Yes, I realize there's no such category, but there *should*
> > be, which would include:
> >
> > Wireless LAN (non ham-radio)
> > Bluetooth
> > IrDA
>
> IrDA isn't necessarily networking, Bluetooth either.
> Wireless LAN is where it should be.
ok, i can buy that. back to work here ... or, maybe not.
there must be a bowl game on TV somewhere.
rday
> > Multimedia devices
> >
> > How come "Sound" is not here? And (as we've already
> > established), Radio Adapters is not a sub-entry of Video for
> > Linux. :-) (And is there a reason why Amateur Radio Support
> > and Radio Adapters are so far apart in the config menus?
>
> Yeah, this one is a puzzle. <g>
Amateur Radio Support contains options to do with things like ham
radio modem support.
Radio Adaptors contains options to do with radio tuner cards.
Radio adaptors was originally put together with Video for Linux,
because when there were only a few radio adaptors supported, it seemed
logical to group them with video capture cards, which often have
television tuners on them.
Most of the illogical grouping of configuration options has come about
because of the way the kernel has evolved.
For example, before IDE and SCSI CD-ROM drives because popular, CD-ROM
drives were a completely separate configuration category. Now that
IDE and SCSI CD-ROM drives are much more popular than proprietary
interface CD-ROM drives, the configuration options for them are
grouped with the IDE and SCSI options.
John.
On Wed, 1 Jan 2003, Tomas Szepe wrote:
[snippage]
| > It seems that the final option, "Preemptible kernel", does
| > not belong there. In fact, there seem to be a number of
| > kernel-related, kind of hacking/debugging options, that
| > could be collected in one place, like preemption, sysctl,
| > hacking, executable file formats, etc. "Low-level kernel
| > options", perhaps?
So long as they come after the processor selection or whatever
dependencies they have.
| Should go to "General config" IMHO.
But is General Config still above processor selection?
I made a patch for a second "More general config" at the end
of the main menu so that dependencies can be used.
Andrew Morton has it queued in -mm now.
| > Bus options (PCI, PCMCIA, EISA, MCA, ISA)
| >
| > First, there's no hint from that heading that hot-pluggable
| > settings are hidden under there as well.
|
| Well, PCMCIA pretty much suggests that, doesn't it?
|
| > In addition, why does "Bus options" not include the USB bus,
| > the I2C bus, FireWire, etc? A bus is a bus, isn't it?
|
| Yes, this is a valid comment. Placing USB under "Bus options"
| should be totally straightforward, but that one's for Greg KH
| to decide.
USB needs to follow the Input subsystem unless there's something
else going on regarding dependencies.
| > Multimedia devices
| >
| > How come "Sound" is not here? And (as we've already
| > established), Radio Adapters is not a sub-entry of Video for
| > Linux. :-) (And is there a reason why Amateur Radio Support
| > and Radio Adapters are so far apart in the config menus?
I agree.
Greg Banks has (had) a real nice program for checking
dependency ordering using Config.in files. It would be
very nice if it now worked with Kconfig files. :)
It could be used for this type of config reordering to
verify that things weren't screwed up. I used it when
I moved Network Devices to just under/after Network Options
to show that no dependency ordering was mangled by that patch.
--
~Randy
On Wed, 1 Jan 2003, Randy.Dunlap wrote:
> Greg Banks has (had) a real nice program for checking
> dependency ordering using Config.in files. It would be
> very nice if it now worked with Kconfig files. :)
> It could be used for this type of config reordering to
> verify that things weren't screwed up. I used it when
> I moved Network Devices to just under/after Network Options
> to show that no dependency ordering was mangled by that patch.
so are you saying that there should be no backward dependencies
in the list of menus? i remember just that in the 2.4 screens,
when you could select hardware sensors and then, on a
subsequent screen, deselect I2C which would, as a result,
deselect sensors on that previous screen.
you're saying that, the way these menus are ordered, this
type of thing should be avoided?
rday
> [[email protected]]
>
> On Wed, 1 Jan 2003, Tomas Szepe wrote:
>
> [snippage]
> | > It seems that the final option, "Preemptible kernel", does
> | > not belong there. In fact, there seem to be a number of
> | > kernel-related, kind of hacking/debugging options, that
> | > could be collected in one place, like preemption, sysctl,
> | > hacking, executable file formats, etc. "Low-level kernel
> | > options", perhaps?
>
> So long as they come after the processor selection or whatever
> dependencies they have.
No longer an issue, see below.
> ...
>
> | > Multimedia devices
> | >
> | > How come "Sound" is not here? And (as we've already
> | > established), Radio Adapters is not a sub-entry of Video for
> | > Linux. :-) (And is there a reason why Amateur Radio Support
> | > and Radio Adapters are so far apart in the config menus?
>
> I agree.
>
> Greg Banks has (had) a real nice program for checking
> dependency ordering using Config.in files. It would be
> very nice if it now worked with Kconfig files. :)
Forward references work nicely with the new configurator,
see for yourself (patch against 2.5.53):
diff -urN a/init/Kconfig b/init/Kconfig
--- a/init/Kconfig 2002-12-16 07:02:05.000000000 +0100
+++ b/init/Kconfig 2003-01-02 03:49:02.000000000 +0100
@@ -1,6 +1,10 @@
menu "Code maturity level options"
+config HRM0PS
+ depends on HRMOPS_PREREQUISITE
+ bool "This proves that forward-referenced symbols work just fine"
+
config EXPERIMENTAL
bool "Prompt for development and/or incomplete code/drivers"
---help---
diff -urN a/net/Kconfig b/net/Kconfig
--- a/net/Kconfig 2002-12-08 20:06:41.000000000 +0100
+++ b/net/Kconfig 2003-01-02 03:49:44.000000000 +0100
@@ -5,6 +5,9 @@
menu "Networking options"
depends on NET
+config HRMOPS_PREREQUISITE
+ bool "Switch this on for some serious HRM0PS!!"
+
config PACKET
tristate "Packet socket"
---help---
--
Tomas Szepe <[email protected]>
On Wed, 1 Jan 2003, Robert P. J. Day wrote:
| On Wed, 1 Jan 2003, Randy.Dunlap wrote:
|
| > Greg Banks has (had) a real nice program for checking
| > dependency ordering using Config.in files. It would be
| > very nice if it now worked with Kconfig files. :)
| > It could be used for this type of config reordering to
| > verify that things weren't screwed up. I used it when
| > I moved Network Devices to just under/after Network Options
| > to show that no dependency ordering was mangled by that patch.
|
| so are you saying that there should be no backward dependencies
| in the list of menus? i remember just that in the 2.4 screens,
| when you could select hardware sensors and then, on a
| subsequent screen, deselect I2C which would, as a result,
| deselect sensors on that previous screen.
|
| you're saying that, the way these menus are ordered, this
| type of thing should be avoided?
Tomas Szepe just corrected me on this...no longer an issue.
Thanks,
--
~Randy
On Wed, 1 Jan 2003, Robert P. J. Day wrote:
> Loadable module support
>
> Does "Module unloading" mean whether or not I can run "rmmod"?
> And if I deselect this, why can I still select "Forced module
> unloading"? Either I can unload or I can't, no?
I think that one is an error.
>
> And what's the rationale behind making unloading an option,
> anyway? If I want loadable module support, is it really a
> big deal to assume I'll want the ability to unload them as
> well? Just curious, that's all. Under what circumstances
> would I explicitly *not* want the ability to rmmod? Tight
> space embedded kernels, possibly?
I would encourage Rusty to answer, or you to read the archives.
>
> Processor family
>
> It seems that the final option, "Preemptible kernel", does
> not belong there. In fact, there seem to be a number of
> kernel-related, kind of hacking/debugging options, that
> could be collected in one place, like preemption, sysctl,
> hacking, executable file formats, etc. "Low-level kernel
> options", perhaps?
This makes sense. Certainly a better term than "kernel hacking" if other
things are included. And stack checking, etc, aren't really hacking
anyway...
>
> Bus options (PCI, PCMCIA, EISA, MCA, ISA)
>
> First, there's no hint from that heading that hot-pluggable
> settings are hidden under there as well.
Which hot plugging, PCMCIA or PCI? I'm not sure they're a problem where
they are.
>
> In addition, why does "Bus options" not include the USB bus,
> the I2C bus, FireWire, etc? A bus is a bus, isn't it?
A fine idea.
>
> Multimedia devices
>
> How come "Sound" is not here? And (as we've already
> established), Radio Adapters is not a sub-entry of Video for
> Linux. :-) (And is there a reason why Amateur Radio Support
> and Radio Adapters are so far apart in the config menus?
>
> Wireless networking/protocols
>
> Yes, I realize there's no such category, but there *should*
> be, which would include:
>
> Wireless LAN (non ham-radio)
> Bluetooth
> IrDA
On this whole thing, I would say that a more intuitive layout might have
all media interfaces as next level choices, video, sound, etc. Then have
all wireless devices in another menu, possibly with amateur radio as a
submenu, along with anything else which connects with a non-wire.
>
> anyway, just some observations from someone who doesn't
> know any better.
Who better to offer idea about what is and isn't intuitive? Kernel config
in 2.4 is just short of an adventure game. 2.5 is getting much better, but
there are parts of it which still don't adhere to Plauger's "law of least
astonishment."
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Wed, Jan 01, 2003 at 02:55:01PM -0500, Robert P. J. Day wrote:
>...
> Loadable module support
>
> Does "Module unloading" mean whether or not I can run "rmmod"?
> And if I deselect this, why can I still select "Forced module
> unloading"? Either I can unload or I can't, no?
>...
Thanks for spotting this, after reading kernel/module.c it seems obvious
to me that you are right. The following simple patch fixes it:
--- linux-2.5.54/init/Kconfig.old 2003-01-08 00:05:12.000000000 +0100
+++ linux-2.5.54/init/Kconfig 2003-01-08 00:05:38.000000000 +0100
@@ -127,7 +127,7 @@
config MODULE_FORCE_UNLOAD
bool "Forced module unloading"
- depends on MODULES && EXPERIMENTAL
+ depends on MODULE_UNLOAD && EXPERIMENTAL
help
This option allows you to force a module to unload, even if the
kernel believes it is unsafe: the kernel will remove the module
> rday
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Wed, Jan 01, 2003 at 02:55:01PM -0500, Robert P. J. Day wrote:
>...
> Processor family
>
> It seems that the final option, "Preemptible kernel", does
> not belong there. In fact, there seem to be a number of
> kernel-related, kind of hacking/debugging options, that
> could be collected in one place, like preemption, sysctl,
> hacking, executable file formats, etc. "Low-level kernel
> options", perhaps?
>...
Robert, could you comment on whether it's really needed to have the
preemt option defined architecture-dependant?
After looking through the arch/*/Kconfig files it seems to me that the
most problematic things might be architecture-specific parts of other
architecturs that don't even offer PREEMPT and the depends on CPU_32 in
arch/arm/Kconfig.
> anyway, just some observations from someone who doesn't
> know any better.
IMHO your comments are very valuable.
> rday
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Tue, 2003-01-07 at 18:30, Adrian Bunk wrote:
> Robert, could you comment on whether it's really needed to have the
> preemt option defined architecture-dependant?
>
> After looking through the arch/*/Kconfig files it seems to me that the
> most problematic things might be architecture-specific parts of other
> architecturs that don't even offer PREEMPT and the depends on CPU_32 in
> arch/arm/Kconfig.
I think it should be there. Plus, as you say, it is defined
per-architecture.
The real problem in my opinion is that the category is misnamed. It is
not "processor options" except for the first couple. The majority of
the options should be under a title of "core" or "architecture" or
"system options" in my opinion.
Robert Love
On Tue, Jan 07, 2003 at 06:42:16PM -0500, Robert Love wrote:
> On Tue, 2003-01-07 at 18:30, Adrian Bunk wrote:
> > Robert, could you comment on whether it's really needed to have the
> > preemt option defined architecture-dependant?
> >
> > After looking through the arch/*/Kconfig files it seems to me that the
> > most problematic things might be architecture-specific parts of other
> > architecturs that don't even offer PREEMPT and the depends on CPU_32 in
> > arch/arm/Kconfig.
>
> I think it should be there. Plus, as you say, it is defined
> per-architecture.
>
> The real problem in my opinion is that the category is misnamed. It is
> not "processor options" except for the first couple. The majority of
> the options should be under a title of "core" or "architecture" or
> "system options" in my opinion.
On ARM, it doesn't appear under "processor options" but under
"General Setup", which is where it fits best, along with the other
general core features of the kernel. It does depend on a processor
option, but there should not be any problem with that. ARM _does
not_ support preempt on 26-bit ARM CPUs, so we _explicitly_ disallow
selection of that configuration.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On 7 Jan 2003, Robert Love wrote:
> The real problem in my opinion is that the category is misnamed. It is
> not "processor options" except for the first couple. The majority of
> the options should be under a title of "core" or "architecture" or
> "system options" in my opinion.
>
> Robert Love
Someone else suggested putting all the low level options like preempt,
smp, and the stuff in kernel-hacking into a single menu, with a better
name.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Wed, 2003-01-08 at 09:32, Bill Davidsen wrote:
> Someone else suggested putting all the low level options like preempt,
> smp, and the stuff in kernel-hacking into a single menu, with a better
> name.
I do not think I like this. SMP, kernel preemption, and high memory
support are the three most fundamental choices one makes during
configuration.
They should be out in the open, in the beginning, in a well-labeled
category. They only issue I see is "processor options" should be
renamed "core options" or whatever. But that is trivial.
Robert Love
On 8 Jan 2003, Robert Love wrote:
> On Wed, 2003-01-08 at 09:32, Bill Davidsen wrote:
>
> > Someone else suggested putting all the low level options like preempt,
> > smp, and the stuff in kernel-hacking into a single menu, with a better
> > name.
>
> I do not think I like this. SMP, kernel preemption, and high memory
> support are the three most fundamental choices one makes during
> configuration.
I guess, depending on your definition of fundemental. I would put any
option which affects the kernel as a whole in that category, myself.
Compiling with frame pointers comes to mind, since every object file is
changed and there are performance implications as well.
> They should be out in the open, in the beginning, in a well-labeled
> category. They only issue I see is "processor options" should be
> renamed "core options" or whatever. But that is trivial.
Processor option would select the processor and any architecture dependent
options, I would think. Something like "kernel characteristics" could have
options like smp.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Wed, Jan 08, 2003 at 01:36:06PM -0500, Bill Davidsen wrote:
> I guess, depending on your definition of fundemental. I would put any
> option which affects the kernel as a whole in that category, myself.
> Compiling with frame pointers comes to mind, since every object file is
> changed and there are performance implications as well.
No-one other than kernel hackers should be playing with that option,
hence it's in the kernel hacking menu.
> Processor option would select the processor and any architecture dependent
> options, I would think. Something like "kernel characteristics" could have
> options like smp.
SMP isn't a processor option ?
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Wed, 8 Jan 2003, Dave Jones wrote:
> On Wed, Jan 08, 2003 at 01:36:06PM -0500, Bill Davidsen wrote:
>
> > I guess, depending on your definition of fundemental. I would put any
> > option which affects the kernel as a whole in that category, myself.
> > Compiling with frame pointers comes to mind, since every object file is
> > changed and there are performance implications as well.
>
> No-one other than kernel hackers should be playing with that option,
> hence it's in the kernel hacking menu.
Anyone who wants to be able to debug a problem should be playing with
that, it's one thing which affects the whole kernel, and is't really a
hack in the usualy sense. And sysctl isn't really a hack, it's just
another feature (my opinion).
> > Processor option would select the processor and any architecture dependent
> > options, I would think. Something like "kernel characteristics" could have
> > options like smp.
>
> SMP isn't a processor option ?
Clearly not, it's not processor dependent or even architecture dependent
generally. It's a characteristic of the os, unlike microcode, mtrr, and
other stuff not on some architectures. You can select it for 386/486/P5
(and it works in 2.4 at least, for P5, have several).
I would think that processor options would select the processor and any
options which are specific to it rather than generally supported. Serial
numbers, firmware loads, that sort of feature.
Preempt and smp, are general, I guess not supported on every possible
hardware, but certainly not restricted to a single model or family.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Wed, Jan 08, 2003 at 05:49:54PM -0500, Bill Davidsen wrote:
> > No-one other than kernel hackers should be playing with that option,
> > hence it's in the kernel hacking menu.
> Anyone who wants to be able to debug a problem should be playing with
> that
If someone is debugging a kernel, they are by definition, kernel
hacking. They should know where the kernel hacking menu is.
> > SMP isn't a processor option ?
> Clearly not, it's not processor dependent or even architecture dependent
Of course its arch dependant. Some of the archs we support don't do SMP.
See m68k for one. Sure there may be some boards out there with >1 68k
welded to them, but Linux doesn't run on them.
> generally. It's a characteristic of the os, unlike microcode, mtrr, and
> other stuff not on some architectures.
Absolute nonsense. These are _cpu_ features. If you dispute this,
you have no understanding of what you talking about.
> You can select it for 386/486/P5
> (and it works in 2.4 at least, for P5, have several).
And thats perfectly valid. Although I've not seen an MP compliant
386/486 personally, there were patches I beleive at one time for
some of the strange 486 implementations.
It's also a valid thing to do to do for code coverage reasons.
Although I doubt anyones testing SMP builds on a 386/486 any more.
> I would think that processor options would select the processor and any
> options which are specific to it rather than generally supported. Serial
> numbers, firmware loads, that sort of feature.
serial number stuff is done at run time. Firmware loads. Well, you
mentioned above that microcode wasn't a CPU feature, now you change
your mind ?
> Preempt and smp, are general, I guess not supported on every possible
> hardware
Again, more contradiction. Above you said of SMP:
"Clearly not, it's not processor dependent or even architecture dependent"
Now you're saying it is arch dependant.
Which Bill am I arguing with here ?
>From x86 POV, a preemptive SMP 386 kernel should boot.
Its the only way to guarantee that you get both features in a kernel
that will run on anything from 386 up.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
DJ> > Processor option would select the processor and any architecture dependent
DJ> > options, I would think. Something like "kernel characteristics" could have
DJ> > options like smp.
DJ> SMP isn't a processor option ?
DJ> Dave
Good day!
I think, first of all it's "General Kernel options(features)" to
support SMP(Preempt, MTRR) or not.
And may be would be better to move Processor Family and SubArch menu
to the top level of the menu? Then merge "General setup" and "Processor
type and features" in one menu.
It's just my opinion, no more.
Ruslan mailto:[email protected]
On Thu, 9 Jan 2003, Dave Jones wrote:
> On Wed, Jan 08, 2003 at 05:49:54PM -0500, Bill Davidsen wrote:
> > > SMP isn't a processor option ?
> > Clearly not, it's not processor dependent or even architecture dependent
>
> Of course its arch dependant. Some of the archs we support don't do SMP.
> See m68k for one. Sure there may be some boards out there with >1 68k
> welded to them, but Linux doesn't run on them.
Exactly, that's not a characteristic of the CPU, it's a system board thing
and support is really a low level kernel option.
> > generally. It's a characteristic of the os, unlike microcode, mtrr, and
> > other stuff not on some architectures.
>
> Absolute nonsense. These are _cpu_ features. If you dispute this,
> you have no understanding of what you talking about.
No, you missed what I was talking about... reread the above, I said SMP
was an os feature *unlike* mtrr, etc.
> > You can select it for 386/486/P5
> > (and it works in 2.4 at least, for P5, have several).
>
> And thats perfectly valid. Although I've not seen an MP compliant
> 386/486 personally, there were patches I beleive at one time for
> some of the strange 486 implementations.
>
> It's also a valid thing to do to do for code coverage reasons.
> Although I doubt anyones testing SMP builds on a 386/486 any more.
>
> > I would think that processor options would select the processor and any
> > options which are specific to it rather than generally supported. Serial
> > numbers, firmware loads, that sort of feature.
>
> serial number stuff is done at run time. Firmware loads. Well, you
> mentioned above that microcode wasn't a CPU feature, now you change
> your mind ?
>
> > Preempt and smp, are general, I guess not supported on every possible
> > hardware
>
> Again, more contradiction. Above you said of SMP:
> "Clearly not, it's not processor dependent or even architecture dependent"
> Now you're saying it is arch dependant.
In general by architecture dependent I meant "specific to one
architecture" or even one processor. HT is only on one type of CPU, mtrr
is on one family of CPUs, etc. As opposed to SMP, which is possible on any
of the supported CPUs, even if there isn't a Linux supported example of
it. There was even a board mounting two AMD Socket7 CPUs with a bunch of
glue which ran some BSD variant (no VM, I assume).
I don't mind you disagreeing with me, I'd appreciate it if you would stop
misreading what I said and then claiming I don't know I'm talking about.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
In message <[email protected]> you write:
> Thanks for spotting this, after reading kernel/module.c it seems obvious
> to me that you are right. The following simple patch fixes it:
Yep. Linus, please apply.
From: Adrian Bunk <[email protected]>
--- linux-2.5.54/init/Kconfig.old 2003-01-08 00:05:12.000000000 +0100
+++ linux-2.5.54/init/Kconfig 2003-01-08 00:05:38.000000000 +0100
@@ -127,7 +127,7 @@
config MODULE_FORCE_UNLOAD
bool "Forced module unloading"
- depends on MODULES && EXPERIMENTAL
+ depends on MODULE_UNLOAD && EXPERIMENTAL
help
This option allows you to force a module to unload, even if the
kernel believes it is unsafe: the kernel will remove the module
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.