Kai Henningsen wrote:
>
>
> For what use? There are only the four options.
>
And because of this way of thinkin there will be,
forever, only four options, everywhere.
There is allways like discussion like that:
KISS, resources, extentsibility, KISS, resources...
instead of just doing it modular and let
end-user pick the options.
No, it would not be much more code.
the same amount of lines of code
and somewhat more initialization time
binary code (which is released after use)
and even less binary code if all of this
non-performance critical interfaces
would be in separate modules.
> > Why to create just another messy interface
> I don't know, why *do* you propose one such?
cause OO interfaces have proved themseleves
to be manageable, unifiable, extentsible, sane.
we are talking here about 2 interfaces:
for coding(macros, calls) and for accessing
(proc, sysctl, khttpd, ioctl, devfs).
> >PLeez, do it the way, that if I want to use it
> >in device driver, then I could be real sure
> >that I never need to rewrite my code.
> That's exactly what the %d proposal seeks to do, yes.
No, it is not. It is quite nice if kernel objects could
be created this way for simple cases, but it is absolutely terrible
if there is no extentsible underlying structures.
Lets spot two goals:
1. Device MIB reading (means: two
to three parameters(device, MIB, attribute) for sanity
or separate structure which essentially duplicates
all of the previous). Also means: locking for 90% of cases.
Means hundreds to thousands of entries per
device(drivers/net/aironet4500_rid.h).
more and more on newer hardware.
2. Networked bridge,router with only khttpd
running and controllable via web browser.
> How would we get at the data without the driver writer creating an
> interface to the data? Impossible. At least *this* interface is
*far*
> simpler than the one you propose.
Coding interface for simple cases for simple drivers.
I am more talking about underlying unified data structure.
For which would the %¤#(/&"#(/&"# coding interface
and /proc , sysctl, khttpd, devfs, ioctl, etc accessing interface
ported-changed again if it is not done good at start.
Instead there could be just a OO style objects hierarcy
and all of those interfaces(accessing, coding) working
on that.
OO way would ensure that it is extentsible and never
needs changed backwards incompatible.
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 : Sun Apr 23 2000 - 21:00:09 EST