[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-kernel
Subject:    Re: bogous binfmt_misc patch in 2.2.0-pre1
From:       Oliver Xymoron <oxymoron () waste ! org>
Date:       1999-01-02 15:17:10
[Download RAW message or body]

On Fri, 1 Jan 1999, Linus Torvalds wrote:

> However, I didn't actually apply the makefile or config patches. I've
> grown tired of the problems with CONFIG_PROC_FS showing up everywhere
> (it's been implicated in just about 90% of all CONFIG_XXXX problems I've
> heard of lately), and I want something better. 
> 
> That "something better" would be to just make everybody act as if
> CONFIG_PROC_FS is always there, but for people who really don't want to
> have the code you just have the register/unregister/whatever functions be
> empty inline functions that always return success (or failure, whatever). 

Are there alternatives to the current proc approach? For instance, it
might be feasable to replace procfs with a usermode filesystem driver that
talks to the kernel via a single binary interface of some sort. 

I think this would have several advantages:

- a large amount of complexity removed from the kernel
- removes formatting policy to user space (this is the big win)
- fewer kernel races if the binary interface is a single syscall
- applications that wanted high-speed access would have binary access
  available
- if you make this a priviledged call, you force the permission policy
  into the userspace tool as well
- the user app could be runtime configurable

Disadvantages:

- current userfs systems may be a little ungainly (but I wouldn't know)
- requires a consistent interface (perhaps like sysctl?)
- version skew issues between user tool and kernel
- some fatal flaw I haven't thought of yet

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

[prev in list] [next in list] [prev in thread] [next in thread]