> 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/