Nice to see again a two cutting-edge-killing opinions.
Every time I really wonder, how such brilliant hackers can be that stupid
that they can not have cake and eat it the same time, and have to scratch
each-others eyes every time.
Use macros.
Kernel has become so big that it really needs universal debugging macros
instead of comments. Comments are waste of brain&fingerpower, if the same
can be explained by long variable names and debug macros.
static Subsystem_module_LocalVariableForThisPurpose;
int Subsytem_module_function_this_and_that(){
DEBUG_ASSERT( Subsystem_module_LocalVariableForThisPurpose == 0 );
DEBUG_ASSERT(MOST_OF_TIME,FS_AREA,MYFS_MODULE, somethingaboutIndodes->node != NULL )
}
Those macros would be acceptable if they are unified and taken to
kernel configuration level, so it would be easy to switch them in/out
not only as boolean option but systematically for different levels,
subsystems and modules.
elmer.
On Sun, 26 Nov 2000, Elmer Joandi wrote:
>
> Kernel has become so big that it really needs universal debugging macros
> instead of comments. Comments are waste of brain&fingerpower, if the same
> can be explained by long variable names and debug macros.
>
> static Subsystem_module_LocalVariableForThisPurpose;
>
> int Subsytem_module_function_this_and_that(){
> DEBUG_ASSERT( Subsystem_module_LocalVariableForThisPurpose == 0 );
> DEBUG_ASSERT(MOST_OF_TIME,FS_AREA,MYFS_MODULE, somethingaboutIndodes->node != NULL )
> }
I would suggest you to read through the following book and files:
* Kernighan & Pike, "The Practice of Programming"
* Documentation/CodingStyle
* drivers/net/aironet4500_proc.c
and consider, erm, discrepancies. On the second thought, reading K&R
might also be useful. IOW, no offense, but your C is bad beyond belief.
On Sun, 26 Nov 2000, Alexander Viro wrote:
> I would suggest you to read through the following book and files:
> * Kernighan & Pike, "The Practice of Programming"
> * Documentation/CodingStyle
> * drivers/net/aironet4500_proc.c
> and consider, erm, discrepancies. On the second thought, reading K&R
> might also be useful. IOW, no offense, but your C is bad beyond belief.
Yep, very true.
aironet4500_proc.c is ugly. And is because there is quickly handwirtten
something that should have been generic for kernel for some long time, not
for every driver-writer to reinvent a wheel.
Note that there is something that virtually elliminates need for
exact user<->kernel level interfaces and userlevel kerneldata manipulation
programs and lots of other maintenance pains.
And it does it in quite short sentences. Plus, half of that file is direct
repeating of some non-exported kernel functions. But, if you think you can
do better, then look into aironet4500_rid.c and handcode it (like real K&R
people do), instead of using aironet4500_proc.c to operate on it.
Also, pcmcia/aironet4500_cs.c has lots of ugly parts. Those which are
related to stupid masohistic code repetitions due to pcmcia package
interface being "cutting edge optimal stupid"
The same true is that 2.4 kernel is, in commercial production sense, late
for 6 months. And reason being that the codebase and testing becomes
unmanageable. And it becomes unmanageable, because some people only read
K&R and try to optimize last bit out of it with using and old book.
I'd really propose again:
1. universal debug macros
2. universalt user-kernelspace configuration interface via proc/sys
I'd really like C++, but it can be done with C and macros.
Some years ago I even managed to write something like stl container
withing C and with macros. That was really screwy thing.
elmer.
Elmer Joandi wrote:
>
> Nice to see again a two cutting-edge-killing opinions.
>
> Every time I really wonder, how such brilliant hackers can be that stupid
> that they can not have cake and eat it the same time, and have to scratch
> each-others eyes every time.
>
> Use macros.
>
> Kernel has become so big that it really needs universal debugging macros
> instead of comments. Comments are waste of brain&fingerpower, if the same
> can be explained by long variable names and debug macros.
>
> static Subsystem_module_LocalVariableForThisPurpose;
>
> int Subsytem_module_function_this_and_that(){
> DEBUG_ASSERT( Subsystem_module_LocalVariableForThisPurpose == 0 );
> DEBUG_ASSERT(MOST_OF_TIME,FS_AREA,MYFS_MODULE, somethingaboutIndodes->node != NULL )
> }
>
>
> Those macros would be acceptable if they are unified and taken to
> kernel configuration level, so it would be easy to switch them in/out
> not only as boolean option but systematically for different levels,
> subsystems and modules.
I leave "debugging" enabled in the drivers I submit. This allows me to
tell customers who are having "It won't detect my card" problems to
enable the debugging output. Most of the time this leads to a resolution
within minutes of me getting the debugging output log.
Sure it will slow the driver down a bit, because of all those bit-test
instructions in the driver. If it bothers you, you get to turn it
off. If you are capable of that, you are also capable enough to turn
it back on when neccesary.
The debug asserts that trigger during normal operation are what make
the Linux kernel stable. Problems get spotted at an early
stage. Problems get fixed. Microsoft disables all debugging before
shipping stuff. That means they don't get useful bugreports from the
field ("When I do this, the system sometimes locks...." compared to
"my system crashes with: 'panic: sk buff underrun at 0xc0123456'").
This was discussed and a decision was taken that we're on the good
track around 5 years ago. I guess that there is some new blood to be
convinced nowadays...
Roger.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
On Sun, 26 Nov 2000, Rogier Wolff wrote:
> Sure it will slow the driver down a bit, because of all those bit-test
> instructions in the driver. If it bothers you, you get to turn it
> off. If you are capable of that, you are also capable enough to turn
> it back on when neccesary.
Now if there would be simple _unified_ system for switching debug code
on/off, it would be a real win. That recompilation-capable enduser would
not need much knowledge to go "General Setup" or newly created
"Optimization" section and switch debugging off/on for _all_ network
drivers or ide drivers for example.
> The debug asserts that trigger during normal operation are what make
> the Linux kernel stable. Problems get spotted at an early
> stage. Problems get fixed.
Yess
Lets say LDBG_* namespace,
macros being in general form:
LDBG_OPERATION(OPTIMIZATION_LEVEL,SUBSYSTEM,MODULE,ACTION, operation params..)
OPERATIONS would be first likely:
ASSERT_PRINT, PRINT, ASSERT_PANIC
OPTIMIZATION_LEVELs would be first:
DEVELOP, ALPHA, BETA, TEST, RELEASE, PRODUCTION, FINETUNED, EMBEDDED
SUBSYSTEMS:
memory, fs, network, drivers(network, fs,...),
divided to about 20 sections or so.
MODULE: would be current module
ACTION: division inside module :
DATA_UP, DATA_DOWN, INIT, CLEANUP, CONFIGURE, ToUserpace,FromUserSpace
... etc. about 15-25 divisions.
LDBG_DECLARE_DEBUG_VAR(OPTIMIZATION_LEVEL, SUBSYSTEM, MODULE)
woudl declare a global unsigned int subsystem_module_debug = 0 and
also sysctl interface to change it.
the var would have ACTION bitfields, so user can control debug output
runtime for the module.
elmer.
Elmer Joandi wrote:
>
>
> On Sun, 26 Nov 2000, Rogier Wolff wrote:
> > Sure it will slow the driver down a bit, because of all those bit-test
> > instructions in the driver. If it bothers you, you get to turn it
> > off. If you are capable of that, you are also capable enough to turn
> > it back on when neccesary.
>
> Now if there would be simple _unified_ system for switching debug code
> on/off, it would be a real win. That recompilation-capable enduser would
> not need much knowledge to go "General Setup" or newly created
> "Optimization" section and switch debugging off/on for _all_ network
> drivers or ide drivers for example.
Now, how is say "Red Hat" (*) going to ship kernels? Of course they are
going to turn off debugging. Then I'll be stuck with a non-recompiling
user-in-trouble with a non-debugging-enabled kernel.
Clients whom I have to tell "please read the kernel-howto" and
recompile your kernel. It's not that hard will not feel "good" about
this. It may seem easy to you, but from some people it is not.
Roger.
(*) Even if I manage to convince Red Hat not to do this, some
distribution is going to claim that they distribute the "performance"
kernel, and disable debugging in the field.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
On Mon, 27 Nov 2000, Rogier Wolff wrote:
> Now, how is say "Red Hat" (*) going to ship kernels? Of course they are
> going to turn off debugging. Then I'll be stuck with a non-recompiling
> user-in-trouble with a non-debugging-enabled kernel.
Red Hat will ship two kernels. Well, they actually ship now about 4 ones
or something. So they will ship 8.
Plus they will ship a script that recompiles kernel without user crawling
in documentation.
It should be an option in linuxconf: recompile local kernel:
debug-nodebug-optimized-localized-nonmodular-server-router-workstation
which compiles and installs 2 hardware/situation optimized/configured
kernels: debug and production.
I am sure company like redhat can ship a little new linuxconf module.
Don't worry, people can make good use of multiple options.
If you provide orthogonal tools they will provide orthogonal solutions.
elmer.
Followup to: <Pine.LNX.4.10.10011270302570.24716-100000@yle-server.ylenurme.sise>
By author: Elmer Joandi <[email protected]>
In newsgroup: linux.dev.kernel
>
> Red Hat will ship two kernels. Well, they actually ship now about 4 ones
> or something. So they will ship 8.
>
Something RedHat & co may want to consider doing is providing a basic
kernel and have, as part of the install procedure or later, an
automatic recompile and install kernel procedure. It could be
automated very easily, and on all but the very slowest of machines, it
really doesn't take that long.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
On Sun, Nov 26, 2000 at 08:25:38PM -0800, H. Peter Anvin wrote:
> Followup to: <Pine.LNX.4.10.10011270302570.24716-100000@yle-server.ylenurme.sise>
> By author: Elmer Joandi <[email protected]>
> In newsgroup: linux.dev.kernel
> >
> > Red Hat will ship two kernels. Well, they actually ship now about 4 ones
> > or something. So they will ship 8.
> >
>
> Something RedHat & co may want to consider doing is providing a basic
> kernel and have, as part of the install procedure or later, an
> automatic recompile and install kernel procedure. It could be
> automated very easily, and on all but the very slowest of machines, it
> really doesn't take that long.
(Note, I work in the GCC group, not the Linux group, so the following is MHO,
and not Red Hat gospel).
Assuming you've installed the compiler/other relevant tools, installed the
kernel source, and have enough disk space to build the kernel. This would
screw people wanting to install Linux on their old 386/486/pentium for use as a
firewall or web server. For example, the machine I'm planning on moving a web
server to only has 2 gig of disk. Right now, I have barely enough space to
hold the compiler tools plus web pages I want to serve. If I was serving much
more content, I would probably chuck the compiler tools/kernel source.
--
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [email protected] phone: +1 978-486-9304
Non-work: [email protected] fax: +1 978-692-4482
Elmer Joandi wrote:
>
>
> On Mon, 27 Nov 2000, Rogier Wolff wrote:
>
> > Now, how is say "Red Hat" (*) going to ship kernels? Of course they are
> > going to turn off debugging. Then I'll be stuck with a non-recompiling
> > user-in-trouble with a non-debugging-enabled kernel.
>
> Red Hat will ship two kernels. Well, they actually ship now about 4 ones
> or something. So they will ship 8.
>
> Plus they will ship a script that recompiles kernel without user crawling
> in documentation.
It's not that Red Hat can't make a script that automatically recompiles
a certain package like the kernel. That's what a source-RPM actually IS.
People will want to upgrade to the latest kernel. People happen to
have deselected the compiler, or another essential tool for compiling
the kernel.
I've had LOTS of trouble myself when I wanted to upgrade a certain
machine which happened to be a '486 with 16M RAM intended as a
mail-router. So the machine had a minimal install: It started out with
a 170Mb disk. And you want 100Mb of mail-spool don't you. Well try and
cram a current distribution into 80M. That's kind of hard. So I had
agressively removed all packages I didn't need. Then suddenly there is
stuff that requires a kernel recompile (and it didn't want to work on
the system that I have for kernel-compiles), and you find out that if you
don't do the recommended install you miss quite a lot of packages that
are required for the kernel compile.
That's the kind of trouble that people end up running into. It took me
a while to figure it out. What do you expect from non-kernel hacking
random citizens?
The idea is, by the way, that you NEVER EVER want to run a kernel
without the double checks. Donald has a define at the top of his
drivers that defines the debug level, and I've never seen that at
"production". Similarly there are lots of "debugging" asserts in the
Linux kernel, that theoretically can go. Those need to stay to keep
Linux from crashing uncontrollably when things go slightly bad.
"Slightly bad" could be that a bit in memory falls over. "Slightly
bad" could be that a new bug in a driver is about to be found.
Andries calls this "globally correct". If your analysis of the kernel
finds that some assertion always holds, you could remove the check for
this pre-condition (the "assertions). Turns out that people will
prefer to run the "performance" kernel, and they will send in useless
bugreports like "my just hangs" much more often than now.
We'll end up in the current Windows situation where rebooting is
likely to help out. At first Linux will still be as stable as it is
now, but as soon as we start to lose half the useful bugreports to the
"sudden-hang"(*) monster, we'll quickly go downhill towards the
current state-of-affairs with MSWindows.
Roger.
(*) Or the "crashes spectacularly a few hours after the problem
actually accurred".
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
On Mon, 27 Nov 2000, Rogier Wolff wrote:
> Turns out that people will
> prefer to run the "performance" kernel, and they will send in useless
> bugreports like "my just hangs" much more often than now.
But look at positive side:
1. really few people run development kernels despite the "performance" so
it probably will be with nondebug kernels.
2. production kernels get more solid
3. because there could be a lot more debug points in development kernels
4. Distributors are interested in shipping debug-kernels.
You see the part that lots of asserts and debug prints may go.
I see the advantage, that a lot of them can come, at no cost.
Besides, if you want to have some assert anyway, then do not write it with
system-wide macro but make your own or mark it as "included allways".
Faulty logic.
elmer.
Elmer Joandi wrote:
>
>
> On Mon, 27 Nov 2000, Rogier Wolff wrote:
> > Turns out that people will
> > prefer to run the "performance" kernel, and they will send in useless
> > bugreports like "my just hangs" much more often than now.
>
> But look at positive side:
I disagree:
> 1. really few people run development kernels despite the "performance" so
> it probably will be with nondebug kernels.
Nope. If Red Hat gives a choice between a "performance" and a "with
debugging" kernel, everyone will chose "performance" under the
impression that thye won't be debugging their server.
> 2. production kernels get more solid
Nope. The kernels in production WILL NOT be more solid. They will
crash unexpectedly without any reference to what caused the crash.
> 3. because there could be a lot more debug points in development kernels
No. you state that they would come "at no cost" that would mean that
YOU are suggesting that you'd run a "performance" kernel, with (most)
of the debugging disabled.
Which means that you'd have disabled the debugging in MY part of the
kernel.
> 4. Distributors are interested in shipping debug-kernels.
Even if SuSE, Red Hat and Mandrake are convinced that shipping
debug-kernels is a good idea, then there is going to be some
distribution that has "ships performance kernels" as on of their
selling points. We'll then lose the bug-reports from that part of the
linux-users.
> You see the part that lots of asserts and debug prints may go.
> I see the advantage, that a lot of them can come, at no cost.
> Besides, if you want to have some assert anyway, then do not write
> it with system-wide macro but make your own or mark it as "included
> allways". Faulty logic.
Well, your system-wide macro should have that option. But it will
be too easy to just disable it, and lose the debugging info.
Sure if we'd convert to using your solution right now, we'd leave in
lots of those asserts and debugging prints "by default" exactly as
they are now. There possbily wouldn't even be a byte difference in the
binary. But in time, there will be many places where it is seen as
appropriate to put the test out-of-commission when marked as
"production" kernel.
Roger.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
well, really, look the other side:
We dont make a way to take info away, we just put a lot more into it and
give the option to take it away if it is not needed.
With this you get your usual amount of debug info plus a way to have lots
more.
Oh, and one more point: if linux is going to have nonprofessional endusers
space comparable to MSWin, then you probably do not want to have every bug
report, because these will be stupid anyway, with or without debug info.
But if ideological wars stop development in nonsense places, then that
day wont come anyway.
elmer.
Elmer Joandi wrote:
>
> Now if there would be simple _unified_ system for switching debug code
> on/off, it would be a real win. That recompilation-capable enduser would
> not need much knowledge to go "General Setup" or newly created
> "Optimization" section and switch debugging off/on for _all_ network
> drivers or ide drivers for example.
Reminds me ... <linux/kernel.h> has a "#if DEBUG" statement that blows
up if the debug code does something like "#define DEBUG(X...) printk(X...)".
I came across this recently (think I was debugging PCI code ... not sure).
Changing it to "#ifdef DEBUG" avoids problems.
--
Andrew E. Mileski - Software Engineer
Rebel.com http://www.rebel.com/
"H. Peter Anvin" <[email protected]> writes:
> Something RedHat & co may want to consider doing is providing a basic
> kernel and have, as part of the install procedure or later, an
> automatic recompile and install kernel procedure. It could be
> automated very easily, and on all but the very slowest of machines, it
> really doesn't take that long.
this completely not possible to do in regard of the end-users eyes.
--
MandrakeSoft Inc http://www.chmouel.org
--Chmouel
On Mon, 27 Nov 2000, Andrew E. Mileski wrote:
> Elmer Joandi wrote:
> >
> > Now if there would be simple _unified_ system for switching debug code
> > on/off, it would be a real win. That recompilation-capable enduser would
> > not need much knowledge to go "General Setup" or newly created
> > "Optimization" section and switch debugging off/on for _all_ network
> > drivers or ide drivers for example.
>
> Reminds me ... <linux/kernel.h> has a "#if DEBUG" statement that blows
> up if the debug code does something like "#define DEBUG(X...) printk(X...)".
> I came across this recently (think I was debugging PCI code ... not sure).
> Changing it to "#ifdef DEBUG" avoids problems.
>
> --
> Andrew E. Mileski - Software Engineer
> Rebel.com http://www.rebel.com/
I find that the following works fine:
#ifdef DEBUG
#define DEB(f) f
#else
#define DEB(f)
#endif
code.....
DEB(printk("Lots of stuff, %s, %d, %d, %d\n", string, int0, int1, int2));
In this case, if DEBUG is defined, printk() with its variable-length
parameter list is compiled.
If not, nothing is compiled, everything inside DEB() is simply ignored.
This means that the macros do not, themselves, have to handle variable-
length parameter lists. The preprocessor only handles text as it was
designed to do.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
"Richard B. Johnson" wrote:
>
> On Mon, 27 Nov 2000, Andrew E. Mileski wrote:
> >
> > Reminds me ... <linux/kernel.h> has a "#if DEBUG" statement that blows
> > up if the debug code does something like "#define DEBUG(X...) printk(X...)".
> > I came across this recently (think I was debugging PCI code ... not sure).
> > Changing it to "#ifdef DEBUG" avoids problems.
> >
> > --
> > Andrew E. Mileski - Software Engineer
> > Rebel.com http://www.rebel.com/
>
> I find that the following works fine:
>
> #ifdef DEBUG
> #define DEB(f) f
> #else
> #define DEB(f)
> #endif
Agreed, but that wasn't my point. There is debug code in the current
kernel that defines DEBUG to something non-numeric, which causes
the compile to barf on kernel.h in some cases (try defining DEBUG in
your Makefile). Instances of the offending code (there are SEVERAL)
and kernel.h should be fixed.
Try this from the top level:
grep -r DEBUG * | grep -v DEBUG_ | less
--
Andrew E. Mileski - Software Engineer
Rebel.com http://www.rebel.com/
Chmouel Boudjnah wrote:
>
> "H. Peter Anvin" <[email protected]> writes:
>
> > Something RedHat & co may want to consider doing is providing a basic
> > kernel and have, as part of the install procedure or later, an
> > automatic recompile and install kernel procedure. It could be
> > automated very easily, and on all but the very slowest of machines, it
> > really doesn't take that long.
>
> this completely not possible to do in regard of the end-users eyes.
>
Why not?
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
"H. Peter Anvin" <[email protected]> writes:
> > > Something RedHat & co may want to consider doing is providing a basic
> > > kernel and have, as part of the install procedure or later, an
> > > automatic recompile and install kernel procedure. It could be
> > > automated very easily, and on all but the very slowest of machines, it
> > > really doesn't take that long.
> >
> > this completely not possible to do in regard of the end-users eyes.
> >
>
> Why not?
slow !! end-user want to install a distribution fast !!!
it need a lot to be friendly the compilation (ie: we cannot do only
launch of make xconfig, not everyone now which options to select),
what we can do is a detection of the module and recompile a kernel
with the detected module for recompilation but there is too much error
case that could not be handle.
--
MandrakeSoft Inc http://www.chmouel.org
--Chmouel
Chmouel Boudjnah wrote:
>
> "H. Peter Anvin" <[email protected]> writes:
>
> > > > Something RedHat & co may want to consider doing is providing a basic
> > > > kernel and have, as part of the install procedure or later, an
> > > > automatic recompile and install kernel procedure. It could be
> > > > automated very easily, and on all but the very slowest of machines, it
> > > > really doesn't take that long.
> > >
> > > this completely not possible to do in regard of the end-users eyes.
> > >
> >
> > Why not?
>
> slow !! end-user want to install a distribution fast !!!
>
> it need a lot to be friendly the compilation (ie: we cannot do only
> launch of make xconfig, not everyone now which options to select),
> what we can do is a detection of the module and recompile a kernel
> with the detected module for recompilation but there is too much error
> case that could not be handle.
>
It's not that slow compared to a whole distro install, although you would
of course want to do it *optionally*. You wouldn't want to get into
every single option, of course, but I thought that was obvious
(apparently not.) The drivers and stuff is the least of the problem --
there, you can use modules anyway.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
On Mon, 27 Nov 2000, Andrew E. Mileski wrote:
> "Richard B. Johnson" wrote:
> >
> > On Mon, 27 Nov 2000, Andrew E. Mileski wrote:
> > >
> > > Reminds me ... <linux/kernel.h> has a "#if DEBUG" statement that blows
> > > up if the debug code does something like "#define DEBUG(X...) printk(X...)".
> > > I came across this recently (think I was debugging PCI code ... not sure).
> > > Changing it to "#ifdef DEBUG" avoids problems.
> > >
> > > --
> > > Andrew E. Mileski - Software Engineer
> > > Rebel.com http://www.rebel.com/
> >
> > I find that the following works fine:
> >
> > #ifdef DEBUG
> > #define DEB(f) f
> > #else
> > #define DEB(f)
> > #endif
>
> Agreed, but that wasn't my point. There is debug code in the current
> kernel that defines DEBUG to something non-numeric, which causes
> the compile to barf on kernel.h in some cases (try defining DEBUG in
> your Makefile). Instances of the offending code (there are SEVERAL)
> and kernel.h should be fixed.
>
> Try this from the top level:
> grep -r DEBUG * | grep -v DEBUG_ | less
Yep. I now understand your point.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
"H. Peter Anvin" <[email protected]> writes:
> It's not that slow compared to a whole distro install, although you would
> of course want to do it *optionally*.
that would be for sure, but keep in mind by experiences most people
sent us a /lot/ of bug reports because they don't know how to do even
if we wrote (IT IS ONLY FOR EXPERIENCED PEOPLE). Let say a scenario :
dumb^Hjoe user make a expert install even if he don't have any clue
about what is a kernel or a compiler or even drivers (yep we have some
users like this)
joe user choose to compile kernel
click on everything (sound fun all this checkboxes)
choose to reboot on his kernel (this sound too cook he can make some
uname -r on IRC to show ''his'' kernel)
reboot and sure he put some idiotic options like IDE in modules.
as i said it's a very special case but we have so much strangness in
our buisness...
You may say that don't let the user choose the wrong option (ie:
don't let to choose to put IDE as modules when he has installed on an
only IDE partition), but there is too much case to handle...
> You wouldn't want to get into every single option, of course, but I
what do you purpose of something else of every single of options ?
> thought that was obvious (apparently not.) The drivers and stuff is
> the least of the problem -- there, you can use modules anyway.
sorry i don't see the point, but indeed it could be doable if the
story of joe user didn't exist.
--
MandrakeSoft Inc http://www.chmouel.org
--Chmouel
Chmouel Boudjnah wrote:
>
> "H. Peter Anvin" <[email protected]> writes:
>
> > It's not that slow compared to a whole distro install, although you would
> > of course want to do it *optionally*.
>
> that would be for sure, but keep in mind by experiences most people
> sent us a /lot/ of bug reports because they don't know how to do even
> if we wrote (IT IS ONLY FOR EXPERIENCED PEOPLE). Let say a scenario :
>
> dumb^Hjoe user make a expert install even if he don't have any clue
> about what is a kernel or a compiler or even drivers (yep we have some
> users like this)
> joe user choose to compile kernel
> click on everything (sound fun all this checkboxes)
> choose to reboot on his kernel (this sound too cook he can make some
> uname -r on IRC to show ''his'' kernel)
> reboot and sure he put some idiotic options like IDE in modules.
>
> as i said it's a very special case but we have so much strangness in
> our buisness...
>
> You may say that don't let the user choose the wrong option (ie:
> don't let to choose to put IDE as modules when he has installed on an
> only IDE partition), but there is too much case to handle...
>
> > You wouldn't want to get into every single option, of course, but I
>
> what do you purpose of something else of every single of options ?
>
I'm talking about crap like the global compile options (processor, SMP,
etc.)
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
"H. Peter Anvin" <[email protected]> writes:
> I'm talking about crap like the global compile options (processor, SMP,
> etc.)
that's could be only for the experienced user and the experienced user
can find how to reboot and compile is own kernel (or even to generate
a distribution with his personal kernel).
--
MandrakeSoft Inc http://www.chmouel.org
--Chmouel
Chmouel Boudjnah wrote:
>
> "H. Peter Anvin" <[email protected]> writes:
>
> > I'm talking about crap like the global compile options (processor, SMP,
> > etc.)
>
> that's could be only for the experienced user and the experienced user
> can find how to reboot and compile is own kernel (or even to generate
> a distribution with his personal kernel).
>
I really don't see that as being true at all. I think you're seriously
limited in your vision.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
"Richard B. Johnson" wrote:
>
> On Mon, 27 Nov 2000, Andrew E. Mileski wrote:
> > Agreed, but that wasn't my point. There is debug code in the current
> > kernel that defines DEBUG to something non-numeric, which causes
> > the compile to barf on kernel.h in some cases (try defining DEBUG in
> > your Makefile). Instances of the offending code (there are SEVERAL)
> > and kernel.h should be fixed.
> >
> > Try this from the top level:
> > grep -r DEBUG * | grep -v DEBUG_ | less
>
> Yep. I now understand your point.
Actually, it would have been clearer with:
grep -r '#define DEBUG' * | grep -v DEBUG_ | less
Given how hard it was to convice Linus to add his coding style guide
to the documentation, as he won't demand conformance, I doubt if there
will be easy getting people to conform to a standard use of DEBUG :(
I'll settle for fixing kernel.h though, and perhaps adding "use of
DEBUG" to the guidelines.
--
Andrew E. Mileski - Software Engineer
Rebel.com http://www.rebel.com/
On Mon, 27 Nov 2000, H. Peter Anvin wrote:
> Chmouel Boudjnah wrote:
> >
> > "H. Peter Anvin" <[email protected]> writes:
> >
> > > > > Something RedHat & co may want to consider doing is providing a basic
> > > > > kernel and have, as part of the install procedure or later, an
> > > > > automatic recompile and install kernel procedure. It could be
> > > > > automated very easily, and on all but the very slowest of machines, it
> > > > > really doesn't take that long.
> > > >
> > > > this completely not possible to do in regard of the end-users eyes.
> > > >
> > >
> > > Why not?
> >
> > slow !! end-user want to install a distribution fast !!!
> >
> > it need a lot to be friendly the compilation (ie: we cannot do only
> > launch of make xconfig, not everyone now which options to select),
> > what we can do is a detection of the module and recompile a kernel
> > with the detected module for recompilation but there is too much error
> > case that could not be handle.
> >
>
> It's not that slow compared to a whole distro install, although you would
> of course want to do it *optionally*. You wouldn't want to get into
> every single option, of course, but I thought that was obvious
> (apparently not.) The drivers and stuff is the least of the problem --
> there, you can use modules anyway.
>
> -hpa
>
End users have bee known to try a kernel compile..
--
Gerhard Mack
[email protected]
<>< As a computer I find your faith in technology amusing.
[Elmer Joandi]
> Oh, and one more point: if linux is going to have nonprofessional
> endusers space comparable to MSWin, then you probably do not want to
> have every bug report, because these will be stupid anyway, with or
> without debug info. But if ideological wars stop development in
> nonsense places, then that day wont come anyway.
What is the name of that corollary to Godwin's Law? You know, the one
about mentioning "competition with Windows" in any discussion about the
need for a given feature in Linux?
See also the one about mentioning "my grandmother reading e-mail" in
any discussion on user interfaces.
Peter