This is typical of the "linux mentality". Why do other OSs have solutions
that work, yet linux's method requires special coding? If it "has to be
done that way", why do other OS's have solutions that dont do it that way?
the size of the buffer is an annoyance but not a serious problem however.
printing directly to the console (as BSD does) is useful when debugging a
panic, as you can trace right to the panic point. Also certain levels of
output will trash the screen, requiring a reset (switching to another
virtual console and then switching back, unfortunately flushing the buffer
will do it). Im not sure if it has been fixed, but also writing without a
newline used to cause garbage to be spewed to the screen, which meant a
screen line had to be used for each message.
At 02:08 PM 10/23/2000, Richard B. Johnson wrote:
>On Mon, 23 Oct 2000, Dennis wrote:
>
> > >
> > >o What used to take a month to get working in SunOS, will
> > >take a few hours on Linux. Linux has continually improved the
> > >resources available to the modules. In the beginning there was
> > >a kernel memory allocator. Now we have common resource allocation
> > >code for I/O addresses like PCI, common interrupt handlers, common
> > >sleep and wake-up routines, etc. Basically, the best ideas of
> > >all the driver contributors have been adapted into a kernel-driver
> > >interface so that every compliant module gets to share the best
> > >code available.
> >
> > As long as your modules are trivial, you are correct. I agree that writing
> > a basic module is fairly easy, and debugging is easy (although if they
> > fixed the printk interface it would be easier), but.....
> >
>
>Some of the stuff we do is hardly trivial. Could you explan what you
>have found wrong with printk()? I have never had any problem with it.
>If you are referring to the limited-size buffering of the output, this
>is not something that requires a "fix". It is deliberate so that even
>and out-of-memory situation can be displayed. Printk()'s buffer is
>allocated once and is fixed-length. If you use printk for what it
>is supposed to be used for, you will never have any problems.
>
>There are other ways than printk() to write output to the current
>task's output. printk() is most useful where there isn't a well-
>defined 'current'.
>
>static void print_string(char *str)
>{
> struct tty_struct *tty = current->tty;
> (*tty->driver.write)(tty, 0, str, strlen(str));
> (*tty->driver.write)(tty, 0, "\r\n", 2);
>}
>
> > "compliance" is difficult without good documentation,and unfortunately
> most
> > of the docs for the linux kernel are in Alan Cox's head (and the like).
> > Virtually all books are out of date by the time they hit the shelves (the
> > linux "device driver" book had many errors and omissions and proved more
> > detrimental than useful). Most of the how-tos are out of date. This,
> > understandable, is what you get for free.
> >
> > Also, the definition of "compliant" keeps changing. the difference
> between
> > a real commercial OS and linux is that linux is a moving target.
> >
>
>Look, if you are doing product development, it's counter-productive to
>use a __development__ kernel. You can spend too much time keeping up
>with the changes. Instead, just like you should never change your tools
>during a product design cycle, you should not change the effective
>kernel you use.
>
>The "stable" kernel, i.e., 2.2.5 -> 2.2.17 has been kept up-to-date
>as far as bug fixes are concerned. My drivers work fine in this
>series.
>
>At some later date, when the current development kernel becomes
>the "stable" kernel, I will make whatever changes are necessary to
>my (at last count) 12 drivers so they work in the new kernel.
>This is something that will happen during the normal product lifetime,
>not before the products are being shipped.
>
>
> > While they might brag about LINUX being "fast moving", it is also the main
> > reason that it is continuously unstable and the hopes of true stability
> > any time soon is questionable. Until they stop hacking core elements and
> > redesigning interfaces on the fly there will be no change. Just lots of
> new
> > features that almost work as long as you use them in a particular way.
> >
> > theres a lot to be said for doing something right the first time and
> > sticking with it even if it isnt perfect. Unfortunately many of the
> > original linux designs were so poorly thought out that they need to be
> > completely redesigned.
> >
>
>Not true. You can't have reviewed or understand any of the kernel code if
>you believe this. All major elements are modular. When somebody comes
>up with better memory management, it's encorporated, better scheduling,
>it's encorporated, etc. This is what development kernels are for.
>
>Bugs that were found when changing the design of various kernel
>procedures, have been back-ported to the stable kernel series.
I never use development kernels, what Im talking about is each major
release is like starting from version 1.0. By the time it stabilizes, the
next major puts it back to square one.
My point is that there is no "stable kernel series". 2.2.0 wasnt stable,
and neither was 2.2.3. Virtually all of the ethernet drivers still lock up
under heavy load in 2.2.17...and now with 2.4 there are more countless
adventures ahead....
an example of "poor planning" is that skput and skpush will panic the
kernel if there is no room (this can happen with multiple encapsulations)
The proper behaviour would be to return a NULL pointer indicating failure,
and then to drop the frame and issue a warning. But, as AC says "we cant
rewrite every driver and it would be inefficient to check every
transaction". However the only way around it is to check the headroom
before you call skput and reallocate the skbuff if there is no room, which
seems a bit more inefficient. In effect, there is a lingering "bug" that is
just tough noogies if it affects you.
DB
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:21 EST