elmer@ylenurme.ee (Elmer Joandi) wrote on 16.04.00 in <38F9EEB1.589C633F@ylenurme.ee>:
> 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.
If you want the end user to control permissions, then you's do some
mechanism for that and use those from the string as defaults. You
cartainly don't want end users to change kernel source to change /proc
file permissions.
> No, it would not be much more code.
The way you described it, I'd estimate about 50 times as much code.
There's a huge difference between exporting a pointer to an int, and
exporting a function that will, somehow, lookup an int.
If you think that's "not much more", I don't know what you're smoking, but
it must be pretty potent.
> and even less binary code if all of this
> non-performance critical interfaces
> would be in separate modules.
You want to duplicate the number of 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.
In certain circumstances. In others, they have proven them to be the exact
opposite.
People who think OO automatically means good just demonstrate that they
don't have a clue.
> we are talking here about 2 interfaces:
> for coding(macros, calls) and for accessing
> (proc, sysctl, khttpd, ioctl, devfs).
We have two interfaces in both proposals. One of them is far smaller and
easier. It's not yours.
> > >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.
Again, what drug are you on?
There are *two* places this interface has extensible structure. One, in
the data structure where the result of parsing that string will be stored;
the other via the %f specifier.
> Lets spot two goals:
> 1. Device MIB reading (means: two
That's a user space function.
> 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.
If you're doing hundreds, let alone thousands of entries per device,
you're doing something *seriously* wrong.
As for locking, there've been separate proposals how to achieve that. I
haven't seen any explanation why those wouldn't work.
> 2. Networked bridge,router with only khttpd
> running and controllable via web browser.
That's nonsense. You can't control anything through khttpd, it just serves
static pages. You'd need an user space web server for that.
> > 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.
Then why are you arguing against the interface?
> 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.
I can't make much sense of that sentence, except for the last half line.
It seems you're saying that the interface would need to be changed, but I
can't see any argument for why that would be.
After all, this interface just creates a tree inside the kernel where you
have (label, data pointer, formatter function) tuples. You can put in half
a dozen different ways of exporting that data without the driver needing
to know anything at all about this.
That's what a clean interface is all about, after all.
> 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.
Your view of OO is unrealistic enough that I must assume you've never been
involved in a nontrivial OO project. OO is no magic bullet.
Anyway, there are a number of good reasons Linux is not written in C++.
MfG Kai
-
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:11 EST