Messages in this thread |  | | Date | Wed, 23 Oct 1996 16:36:17 -0500 (CDT) | From | Ronnie Sanford <> | Subject | Re: 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. > > > >
|  |