lkml.org 
[lkml]   [1996]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: General thoughts for 2.1+
Interesting comment concerning documentation.  Something I haven't 
considered. In our latest release of the Digi driver we have
documentation in both /usr/src/linux/drivers/char/README.epca.dir and
/usr/src/Documentation/digiepca.txt. I did it that way because I thought
that was the way it was supposed to be done. Maybe we should make a
directory in Documentation and put all of our stuff in there..... Is there any
formal documentation (Besides the coding style) standards or coding
standards available for Linux ?
Thanks,
Ronnie Sanford
Digi International


On Wed, 23 Oct 1996, Aaron Tiensivu wrote:

> I'm a little worried this might start something ugly.. but bear with me. :)
>
> The 'Documentation' directory isn't being used by some areas of the kernel
> source. I realize some are probably there for a good reason, but I figured we
> should probably full endorse the idea of a 'Documentation' area.
>
> The offenders:
> ./fs/nfs/README
> ./net/README
> ./net/decnet/README
> ./net/ipv6/README
> ./drivers/net/README1.PLIP
> ./drivers/net/README2.PLIP
> ./drivers/net/README.DLINK
> ./drivers/net/README.wavelan
> ./drivers/net/README.ewrk3
> ./drivers/net/README.de4x5
> ./drivers/net/README.eql
> ./drivers/net/README.tunnel
> ./drivers/net/README.multicast
> ./drivers/net/README.pt
> ./drivers/net/README.smc9
> ./drivers/net/README.dgrs
> ./drivers/block/README.ide
> ./drivers/block/README.hd
> ./drivers/block/README.fd
> ./drivers/block/README.md
> ./drivers/char/README.scc
> ./drivers/char/README.stallion
> ./drivers/char/ftape/README.PCI
> ./drivers/char/README.baycom
> ./drivers/char/README.cyclomY
> ./drivers/scsi/README.st
> ./drivers/scsi/README.aic7xxx
> ./drivers/scsi/README.BusLogic
> ./drivers/scsi/README.g_NCR5380
> ./drivers/scsi/README.AM53C974
> ./drivers/scsi/README.ppa
> ./drivers/scsi/README.FlashPoint
> ./drivers/scsi/README.dtc3x80
> ./drivers/scsi/README.qlogicisp
> ./drivers/scsi/README.qlogicfas
> ./drivers/scsi/README.ncr53c8xx
> ./drivers/scsi/README.in2000
> ./drivers/sound/lowlevel/README
> ./arch/i386/math-emu/README
> ./arch/sparc/boot/README
> ./arch/m68k/ifpsp060/README
> ./arch/m68k/fpsp040/README
> ./scripts/README.Menuconfig
>
> Other areas of concern:
>
> 1. The GGI people need help with getting that project going full-tilt. I'll be
> helping out somehow when time permits. Video card programming is not my forte,
> but I think it is for a very good and valid cause. Their main WWW site is at:
> http://synergy.caltech.edu/~ggi/
>
> Hopefully, maybe I can help out with the ATI Mach32 support and VGAWonder XL
> support. [The two video cards I have]
>
> A small sub-set of GGI might be nice for kernel. Not necessarily a gung-ho
> graphics library, but 'simple' things like being aware of certain extended
> registers of various chipsets. That work fix a majority of the video
> corruption problems we see today.
>
> 2. This is a really minor 'grip' but Paul Gortmaker already posted the patch
> and I think it should probably be stuck in 2.1. It changes the '/proc/interrupts
> ' display to look like:
>
> -----------------------------------------
> olga:~> cat /proc/interrupts
> 0: 19970147 timer
> 1: 180474 keyboard
> 2: 0 cascade
> 3: 138931 + serial
> 4: 600716 (currently free)
> 5: 861 (currently free)
> 6: 111 (currently free)
> 7: 52 (currently free)
> 8: 10495 + rtc
> 9: 2933492 WD8013
> 10: 189 PAS16
> 11: 865252 + BusLogic BT-747A
> 12: 320325 + serial
> 13: 1 math error
> 14: 114459 + ide0
> 15: 197 (currently free)
> olga:~>
> --------------------------------------------
>
> This patch is even more valid with the increased use of modules, in general.
>
> 3. Documentation of the magic cookies found under '/proc/sys' :)
>
> 4. Allow nfsiod processes to die when last mount is unmounted
>
> 5. Clean-up the 'printk' messages in the kernel - giving them at least a
> logging level. This might be a real pain.
>
> 6. If we're going to fix something that's 'broken' in nature and will break
> binaries, let's try to cover as many as possible, early in the 2.1 cycle.
> This way, if we fix things that should be fixed, but might break binary
> compatibility, it'll just be one large upgrade instead of doing something
> half-assed. I don't think I've explained this well, but my main motivation
> is for, in the future, fairly painless updates of kernels for
> 'non-experimental' people. The main goal is so that people won't go nuts and
> complain about procps breaking again, or something like that.
>
> 7. Friendlier kernel panics. I know this goes against the grain of standard
> kernels, but for instance, if you muck up the root drive setting in your
> kernel image, instead of just saying "Kernel panic: cannot find major 03 01"
> (or whatever), it might give you an option of trying /dev/hda2 instead, or
> something.
>
>
>
>

\
 
 \ /
  Last update: 2005-03-22 13:38    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean