ref: Suggested dual human/binary interface for proc/devfs
Seems that people in this discussion split into two groups
by understanding/not understanding that :
1. when the amount of information grows, it needs more and more
formalized/unified ways for description and handling.
2. Efficiency of handling becomes secondary after manageability
and total cost of ownership as amount of information grows.
3. unification and formalization is quite probably impossible
without separating data and metadata(versus non-generated
(handmade in C or yacc) ascii parsers with metadata coded in)
and structuring data into hierarcy as much as possible.
--> This is nothing specific about kernel sources, but kernel
has been growing fast.
At one point there is(or will be) need for unified formal
handling of kernel-internal or hardware-specific structures
and operations.
The point might well be behind as
currently we could have kernel running on 4MB computers
with khttpd/snmpd as only interface to it if all of
kernelland<->userland interfaces would
have been described that way.
It means: www-server enabled cellular phones, dirt-cheap
bridges,routers out of old 4MB386sx16's, whatever other things
where the userland stuff is currently 90% of size and
1% of functionality.
I do not want to argue about the correct way of organization,
but just to express my hope, that this discussion will not
decease until a solution has been found and that in
2.6 kernel there will be unified way to do it.
Certainly there is a way to use open-source potential
by having level of efficiency and indirectness
as a compile-time option.
Some ugliy macro-play for example, which would
pick at compile time between direct/indirect/inline
calls as specified in kernel configuration.
elmer.
-
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/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:15 EST