from my experimenting with 2.6.0-test1-bk2:
1) i mentioned this before, i think, but after one deselects
Power management, should ACPI Support and CPU Frequency
scaling still be available?
the "make xconfig" menu display suggests a submenu
structure there, which clearly isn't the case.
2) can all of the low-level SCSI drivers be made deselectable
in one swell foop? folks might want SCSI support just for
generic support and SCSI (ide-scsi) emulation, but have no
interest in low level SCSI drivers.
so it would be convenient to be able to select the generic
support, and yet not have to deselect low-level drivers
and PCMCIA SCSI adapter support painfully, one at a time.
3) can all of ATM support be deselected with a single click?
in the same way "PCMCIA network device support" is done just
above it under "Networking options"?
rday
> 1) i mentioned this before, i think, but after one deselects
> Power management, should ACPI Support and CPU Frequency
> scaling still be available?
>
> the "make xconfig" menu display suggests a submenu
> structure there, which clearly isn't the case.
>
>
> 2) can all of the low-level SCSI drivers be made deselectable
> in one swell foop? folks might want SCSI support just for
> generic support and SCSI (ide-scsi) emulation, but have no
> interest in low level SCSI drivers.
>
> so it would be convenient to be able to select the generic
> support, and yet not have to deselect low-level drivers
> and PCMCIA SCSI adapter support painfully, one at a time.
>
> 3) can all of ATM support be deselected with a single click?
> in the same way "PCMCIA network device support" is done just
> above it under "Networking options"?
A lot of these add extra complications for anybody not wanting a
'simple' kernel config. _Please_ don't re-design everything the same
way as the once-simple filesystems menu.
Too much prompting is irritating for advanced users, and they are the
people who are likely to compiling the most kernels, rather than
sticking with the kernel that came with their distribution.
John.
On Thu, 24 Jul 2003, John Bradford wrote:
> > 1) i mentioned this before, i think, but after one deselects
> > Power management, should ACPI Support and CPU Frequency
> > scaling still be available?
> >
> > the "make xconfig" menu display suggests a submenu
> > structure there, which clearly isn't the case.
> >
> >
> > 2) can all of the low-level SCSI drivers be made deselectable
> > in one swell foop? folks might want SCSI support just for
> > generic support and SCSI (ide-scsi) emulation, but have no
> > interest in low level SCSI drivers.
> >
> > so it would be convenient to be able to select the generic
> > support, and yet not have to deselect low-level drivers
> > and PCMCIA SCSI adapter support painfully, one at a time.
> >
> > 3) can all of ATM support be deselected with a single click?
> > in the same way "PCMCIA network device support" is done just
> > above it under "Networking options"?
>
> A lot of these add extra complications for anybody not wanting a
> 'simple' kernel config. _Please_ don't re-design everything the same
> way as the once-simple filesystems menu.
>
> Too much prompting is irritating for advanced users, and they are the
> people who are likely to compiling the most kernels, rather than
> sticking with the kernel that came with their distribution.
ok, this one i *am* going to take a stand on -- you're making no
sense whatsoever, so just put down the keyboard and step back.
all of the above three suggestions are for the purpose of either
simplifying the current menu structure or making it more consistent
with the way the rest of the menus are presented. none of them
increase the complexity of *anything*.
how the heck can you refer to "A lot of these" in the context
of three suggestions? get a grip, dude.
and as the complete rookie who took it upon himself to learn
the Kconfig structure so i could bring some order to the filesystems
menu, well, frankly, i *like* that structure, and i haven't heard
any complaints. you seriously think the original structure was
*clearer*?
since i don't have the ability to actually hack down at the code
level, i figured i could still contribute by making it easier for
newbies like myself with simpler and more consistent menus.
apparently, this might not be worth the effort after all.
thanks ever so much for the encouragement.
rday
> > > 1) i mentioned this before, i think, but after one deselects
> > > Power management, should ACPI Support and CPU Frequency
> > > scaling still be available?
> > >
> > > the "make xconfig" menu display suggests a submenu
> > > structure there, which clearly isn't the case.
> > >
> > >
> > > 2) can all of the low-level SCSI drivers be made deselectable
> > > in one swell foop? folks might want SCSI support just for
> > > generic support and SCSI (ide-scsi) emulation, but have no
> > > interest in low level SCSI drivers.
> > >
> > > so it would be convenient to be able to select the generic
> > > support, and yet not have to deselect low-level drivers
> > > and PCMCIA SCSI adapter support painfully, one at a time.
> > >
> > > 3) can all of ATM support be deselected with a single click?
> > > in the same way "PCMCIA network device support" is done just
> > > above it under "Networking options"?
> >
> > A lot of these add extra complications for anybody not wanting a
> > 'simple' kernel config. _Please_ don't re-design everything the same
> > way as the once-simple filesystems menu.
> >
> > Too much prompting is irritating for advanced users, and they are the
> > people who are likely to compiling the most kernels, rather than
> > sticking with the kernel that came with their distribution.
>
> ok, this one i *am* going to take a stand on -- you're making no
> sense whatsoever, so just put down the keyboard and step back.
>
> all of the above three suggestions are for the purpose of either
> simplifying the current menu structure or making it more consistent
> with the way the rest of the menus are presented. none of them
> increase the complexity of *anything*.
>
> how the heck can you refer to "A lot of these" in the context
> of three suggestions? get a grip, dude.
>
> and as the complete rookie who took it upon himself to learn
> the Kconfig structure so i could bring some order to the filesystems
> menu, well, frankly, i *like* that structure, and i haven't heard
> any complaints. you seriously think the original structure was
> *clearer*?
>
> since i don't have the ability to actually hack down at the code
> level, i figured i could still contribute by making it easier for
> newbies like myself with simpler and more consistent menus.
> apparently, this might not be worth the effort after all.
>
> thanks ever so much for the encouragement.
It's not personal, please accept my apologies if it seemed that way,
it's just a co-incidence that the couple of things I don't like were
done by you :-).
The point I'm trying to make is that if you've been using Linux for
years, all these 'clean-ups', that might seem to make things easier
and more organised for new users, really just add extra levels of
indirection for experienced users.
The filesystem menu, for example, I could previously just skip down in
make menuconfig, selecting and deselecting what I wanted. Now, I have
to go in and out, and in and out, just to see what's selected and
what's not. Sure, it might look nice to a new user who doesn't like
to see a lot of options they don't necessarily understand, but it
wastes the time of more experienced users.
Oh well, I'll just go back to the:
vi .config
make oldconfig
kernel configurator.
:-(.
John.
On Thu, Jul 24, 2003 at 08:10:32PM +0100, John Bradford wrote:
>
> The filesystem menu, for example, I could previously just skip down in
> make menuconfig, selecting and deselecting what I wanted. Now, I have
> to go in and out, and in and out, just to see what's selected and
> what's not. Sure, it might look nice to a new user who doesn't like
> to see a lot of options they don't necessarily understand, but it
> wastes the time of more experienced users.
I think we should use "[X] OptionMenu -->" variant USB Gadgets use
where possible. Currently for example IDE code is
ATA/ATAPI/MFM/RLL support -->
<*> ATA/ATAPI/MFM/RLL support
IDE, ATA and ATAPI Block devices -->
<*> Enhandced IDE/MFM/RLL disk/cdrom/...
One level can be completely removed by doing
<*> ATA/ATAPI/MFF/RLL support -->
directly in toplevel menu. Then you do not have to open most of
the menus, as if there is no checkmark before submenu entry, there is
definitely nothing selected below.
And after all, there is also "make menuconfig MENUCONFIG_MODE=single_menu".
Unfortunately it starts with all nodes closed, and '*' (which I'm used
to use for unrolling complete subtree) does nothing. And
second problem is that "<*> XXX -->" does not work as expected in
single_menu mode, it still creates its own submenu, which kinda complicates
things.
Best regards,
Petr Vandrovec
> [[email protected]]
>
> 1) i mentioned this before, i think, but after one deselects
> Power management, should ACPI Support and CPU Frequency
> scaling still be available?
>
> the "make xconfig" menu display suggests a submenu
> structure there, which clearly isn't the case.
Why don't you go ahead and send a patch?
> 2) can all of the low-level SCSI drivers be made deselectable
> in one swell foop? folks might want SCSI support just for
> generic support and SCSI (ide-scsi) emulation, but have no
> interest in low level SCSI drivers.
Add a SCSI lowlevel drivers submenu (~4 lines of Kconfig).
> 3) can all of ATM support be deselected with a single click?
> in the same way "PCMCIA network device support" is done just
> above it under "Networking options"?
Send a patch.
--
Tomas Szepe <[email protected]>
> [[email protected]]
>
> The filesystem menu, for example, I could previously just skip down in
> make menuconfig, selecting and deselecting what I wanted. Now, I have
> to go in and out, and in and out, just to see what's selected and
> what's not. Sure, it might look nice to a new user who doesn't like
> to see a lot of options they don't necessarily understand, but it
> wastes the time of more experienced users.
I'll be sending a patch to fix up this horrid thing shortly.
--
Tomas Szepe <[email protected]>
On Sat, 26 Jul 2003, Tomas Szepe wrote:
> > [[email protected]]
> >
> > 1) i mentioned this before, i think, but after one deselects
> > Power management, should ACPI Support and CPU Frequency
> > scaling still be available?
> >
> > the "make xconfig" menu display suggests a submenu
> > structure there, which clearly isn't the case.
>
> Why don't you go ahead and send a patch?
>
> > 2) can all of the low-level SCSI drivers be made deselectable
> > in one swell foop? folks might want SCSI support just for
> > generic support and SCSI (ide-scsi) emulation, but have no
> > interest in low level SCSI drivers.
>
> Add a SCSI lowlevel drivers submenu (~4 lines of Kconfig).
>
> > 3) can all of ATM support be deselected with a single click?
> > in the same way "PCMCIA network device support" is done just
> > above it under "Networking options"?
>
> Send a patch.
i'd be happy to, but based on my previous experience sending
in a few patches, it's just not worth the aggravation any more.
just one of my patches that got adopted took, literally, several
weeks of being dropped on the floor with no reason why. and i
had to resubmit it, slightly updated, for every BK rev of the
kernel since the previous patch wouldn't apply cleanly --
it might be a line or two off, which would require remaking
the patch and resubmitting it *again*. at which point, it
would be dropped on the floor *again*.
don't get me wrong -- i understand that there has to be some
form of QA in accepting kernel patches, and after a while,
regular submitters can build up a reputation.
but, at this point, it's not terribly useful to encourage people
to submit patches if those patches are just tossed.
it's like the classic catch-22:
"we can't hire you. you don't have enough experience doing
this job."
"ok, so how do i get experience?"
"well, you have to do this job for a while."
uh, right. so, while there's not much point in my submitting
patches, i can still toss suggestions from the sidelines, unless
you have some ideas. i'm certainly open to advice.
rday
> > Send a patch.
>
> i'd be happy to, but based on my previous experience sending
> in a few patches, it's just not worth the aggravation any more.
Well, you know the Gandhi routine: Whatever you do will be
insignificant, but it is very important that you do it.
> just one of my patches that got adopted took, literally, several
> weeks of being dropped on the floor with no reason why.
Trivial patches need to go to people like AC who tend to focus
on aggregating fixes and are in a much better position to push
upstream.
> "we can't hire you. you don't have enough experience doing
> this job."
> "ok, so how do i get experience?"
> "well, you have to do this job for a while."
At which point you must get yossarian-ish enough to start a company.
--
Tomas Szepe <[email protected]>
On Sat, 26 Jul 2003, Tomas Szepe wrote:
> > [[email protected]]
> >
> > The filesystem menu, for example, I could previously just skip down in
> > make menuconfig, selecting and deselecting what I wanted. Now, I have
> > to go in and out, and in and out, just to see what's selected and
> > what's not. Sure, it might look nice to a new user who doesn't like
> > to see a lot of options they don't necessarily understand, but it
> > wastes the time of more experienced users.
>
> I'll be sending a patch to fix up this horrid thing shortly.
i give up. you encourage me to send in patches, then an hour
later announce that you're submitting a patch to, as i read it,
undo my previous "horrid" submission?
are you schizophrenic, or just simply a jerk? really, enquiring
minds would like to know.
time to take a break and go to the gym. i can't take much more
of this idiocy.
rday
Hi Folks,
Thanks for all, for assisting me in solving the
kernel booting problem.
Now I am encountering another problem, after
successful compilation/installation/booting of kernel
2.6.0-test1 , the modules are not loading at all ,
even after installing the latest version of
"module-init-tools-0.9.13-pre" .
Below given the error message that is display during
booting time, when kernel checks for the hardware !
"XT3 FS on hda9, internal journal
Adding 538136k swap on /dev/hda10. Priority:-1
extents:1
kudzu: numerical sysctl 1 23 is obsolete.
warning: process `update' used the obsolete bdflush
system call
Fix your initscripts?
warning: process `update' used the obsolete bdflush
system call
Fix your initscripts?
kudzu: numerical sysctl 1 23 is obsolete.
module_upgrade: numerical sysctl 1 23 is obsolete.
module_upgrade: numerical sysctl 1 49 is obsolete.
module_upgrade: numerical sysctl 1 49 is obsolete.
kudzu: numerical sysctl 1 23 is obsolete.
updfstab: numerical sysctl 1 23 is obsolete.
updfstab: numerical sysctl 1 49 is obsolete.
updfstab: numerical sysctl 1 49 is obsolete.
kudzu: numerical sysctl 1 23 is obsolete."
Because of this, my sound card, D-link FM radio and
other periperal don't work.
Further when I execut the new lsmod command. Module
list is displayed empty.
I appreciate any asistance on this !
Thanks,
Manjunathan PY
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
On Sat, 2003-07-26 at 15:19, Manjunathan Padua Yellappan wrote:
> Now I am encountering another problem, after
> successful compilation/installation/booting of kernel
> 2.6.0-test1 , the modules are not loading at all ,
> even after installing the latest version of
> "module-init-tools-0.9.13-pre" .
What's the output of running the following command as root:
cat /proc/sys/kernel/modprobe
--- Felipe Alfaro Solana <[email protected]>
wrote:
> On Sat, 2003-07-26 at 15:19, Manjunathan Padua
> Yellappan wrote:
> > Now I am encountering another problem, after
> > successful compilation/installation/booting of
> kernel
> > 2.6.0-test1 , the modules are not loading at all ,
> > even after installing the latest version of
> > "module-init-tools-0.9.13-pre" .
>
> What's the output of running the following command
> as root:
>
> cat /proc/sys/kernel/modprobe
The output of the above command is
[root@localhost root]# cat /proc/sys/kernel/modprobe
/sbin/modprobe
[root@localhost root]#
Thanks,
Manjunathan PY
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
On Sat, 26 Jul 2003 08:30:59 -0400 (EDT) "Robert P. J. Day" <[email protected]> wrote:
| On Sat, 26 Jul 2003, Tomas Szepe wrote:
|
| > > [[email protected]]
| > >
| > > 1) i mentioned this before, i think, but after one deselects
| > > Power management, should ACPI Support and CPU Frequency
| > > scaling still be available?
| > >
| > > the "make xconfig" menu display suggests a submenu
| > > structure there, which clearly isn't the case.
| >
| > Why don't you go ahead and send a patch?
Ditto. the right response.
| i'd be happy to, but based on my previous experience sending
| in a few patches, it's just not worth the aggravation any more.
|
| just one of my patches that got adopted took, literally, several
| weeks of being dropped on the floor with no reason why. and i
| had to resubmit it, slightly updated, for every BK rev of the
| kernel since the previous patch wouldn't apply cleanly --
| it might be a line or two off, which would require remaking
| the patch and resubmitting it *again*. at which point, it
| would be dropped on the floor *again*.
|
| don't get me wrong -- i understand that there has to be some
| form of QA in accepting kernel patches, and after a while,
| regular submitters can build up a reputation.
and the QA is on patches, not (so much) on dialog.
| but, at this point, it's not terribly useful to encourage people
| to submit patches if those patches are just tossed.
|
| it's like the classic catch-22:
|
| "we can't hire you. you don't have enough experience doing
| this job."
| "ok, so how do i get experience?"
| "well, you have to do this job for a while."
|
| uh, right. so, while there's not much point in my submitting
| patches, i can still toss suggestions from the sidelines, unless
| you have some ideas. i'm certainly open to advice.
But suggestions from the sidelines are just too close to whinging
(Brit. spelling :) and moaning. Not very helpful.
--
~Randy
> [[email protected]]
>
> i give up. you encourage me to send in patches, then an hour
> later announce that you're submitting a patch to, as i read it,
> undo my previous "horrid" submission?
A bit on the black-or-white side, aren't we today?
I'm merely thinking of turning your submenus into sub-entries
in the main fs menu, because as John has pointed out, the submenus
are rather annoying.
> are you schizophrenic, or just simply a jerk? really, enquiring
> minds would like to know.
Damn, you really do need to take a break.
> I'm merely thinking of turning your submenus into sub-entries
> in the main fs menu, because as John has pointed out, the submenus
> are rather annoying.
Having them as sub-entries would be an improvement all-round, (in my
opinion).
As well as improving the usability of make menuconfig, it's also
better for the make config configurator, because that decends in to
submenus automatically, whereas it prompts for sub-entries.
John.