[lkml]   [2001]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Yet another design for /proc. Or actually /kernel.
Horst von Brand wrote:
> Ricky Beam <> said:
> > >the discussion is irrelevant. Despite what everybody thinks, Linus thinks
> > >/proc must be not binary, so it will stay that way for those of us who run
> > >Linus kernels...
> >
> > Linus has been "wrong" before. It will require good code and numbers
> > backing that codes "goodness" before Linus will begin to listen. Yes,
> > a new procfs format will break a great deal of userland toys, so the
> > changes had better be worth it and sufficient to never, EVER require
> > a complete overhaul in the future.
> /proc for process info is a given (many Unices have it, it is nice at least
> for compatibility).
> /proc for random other garbage should go away. To get at some value you can
> get via specialized calls by read(2) also is just kernel bloat.

My absolute favourite is the following in arch/i386/kernel/irq.c!!!!

Disease symptoms like this are distributed all over the kernel code.

static struct proc_dir_entry * root_irq_dir;
static struct proc_dir_entry * irq_dir [NR_IRQS];

#define HEX_DIGITS 8

static unsigned int parse_hex_value (const char *buffer,
unsigned long count, unsigned long *ret)
unsigned char hexnum [HEX_DIGITS];
unsigned long value;
int i;
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:13    [W:0.058 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site