> if a userland daemon is sitting in the call path and catches the change and
> updates a config file, the update is retained just dandy.
Great.
chown(2) is now:
- call kernel
- kernel contacts userland daemon
- daemon starts, reads database of managed files
- daemon looks up the file being chown(2)ed
- daemon grabs configuration file, locks it
- daemon grovels around lucking for right line to fix
- daemon writes out changed file, unlocks it
- daemon tells kernel OK
- kernel changes permissions (perhaps calling daemon again)?
- system call returns
That will look fine in lmbench, that's for sure.
> again, this is silly. it really is. change is always forthcoming. when you
> stop changing, you stop learning and you stagnate and the world passes you
> by.
Agreed. Insisting that a rather trivial naming mechanism solves all the
problems with device management is silly. Even more so as it introduces as
many problems as it really solves, only harder ones. And most of the
problems it "solves" it just pushes into some dark corner, without really
doing anything about them.
> instead of thinking of how this horrible idea impacts you, think of what
> possibilities may lie ahead. improve, don't disparage.
I'm not being impacted by it, personally. Not directly, that is. But if the
Linux kernel gets screwed up because of too many "bright ideas" that just
HAVE to be in the kernel for "possibilities ahead", I _do_ get impacted.
I'm for bright ideas, I'm for change in the kernel. I'm against "just put
it in the kernel, the kernel hackers will make it work somehow".
Please, read "The Mythical Man Month" for a real horror story of where
"possibilities ahead" got a real operating system. Look at the ISO standard
networking protocols, which were also invented by people with stars in
their eyes about "possibilities ahead". Same with the original Apple Mac:
Nice idea, woefully underpowered and overpriced. A certain software giant
also lives on promising "possibilities ahead", and they (with all their
resources!) haven't ever been able to deliver.
Thanks, but no.
-- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
- 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/