Kai Henningsen wrote:
>
>
> 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.
>
one of us is non-willing to think positive.
with a nice infrastructure in kernel, the amount of
C code lines would be the same anyway.
There is just a function or macro which gets
those parameters, one or another way.
Its kindof simple-evident-logical-etc ?
Amount of binary code may 50x diff, yes,
but this is initialization time code.
> If you think that's "not much more", I don't know what you're smoking, but
> it must be pretty potent.
>
have seen in multiple lists that insults like this mark
the point where people start loosing at real arguments.
> You want to duplicate the number of modules?
>
definitely. even more.
With current modutils it looks ugly, but with small
improvements it looks sane and nice.
> People who think OO automatically means good just demonstrate that they
> don't have a clue.
>
OK, give me the clue.
Tell me how many work-hours it is needed for to change current kernel
to export
all meaningful-outside-kernel parameters and operations to userspace ?
All. I mean also those 10% with locking and hardware device parameters.
How it would be done without code-bloat ? Where to get inellectual
resources
(human time) for that ?
> > 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.
>
please, read before you write. I wont comment, just read above...
The way as you understood, we have about 4 interfaces:
coding/accessing myproposal/yourproposal
> 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.
>
oh, jah, I understood. I say, again, for simple cases this CODING
interface
is nice. However, underlying data structure has to be unified.
read it again. I am not talking bad about your favourite baby.
Could I say anything more exact ?
>
> > Lets spot two goals:
> > 1. Device MIB reading (means: two
>
> That's a user space function.
>
nice, then propose a realistic way how 2.6 would have
all devices all MIBs read ?
I dont see it like user space function. Nice to think,
but lots of devices require lock for mib read and
if the MIB description is not with kernel sources,
then it is lost and messy anyway.
I'd propose, that infrastructure for driver-writers,
which helps to create separate mib-modules
easyliy, that would be a winning strategy.
>
> If you're doing hundreds, let alone thousands of entries per device,
> you're doing something *seriously* wrong.
>
why, if all of this stuff is a separate module ?
dont load it if you dont like it !!!
>
> 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.
>
So what is the exact reason khttpd can not read /proc and after some
tweaking,
also accept PUT/POST ?
Take a look at networking stuff - switces,routers, hubs..
all of this manageable stuff has today just a www interface.
I am having here some twenty or so bridges-routers-whatever
stuff in production where the userspace stuff is just for configuring
kernel remotely, I'd be real happy to just get rid of it.
I have here a motorola d160 mobile phone.
unfortunately this old version has only 64kB ram.
but new versions have plenty. The years-old D160
comes with that 68k processor what is inside Sparc 3.
you could propose making glibc more modular,
as an alternative, but kernel-only operation seems
to be closer.
>
> > 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?
>
Cause it is kindof miracle. If underlying data structures aren't
good, it just postpones, not solves the problem about kernel<->userspace
interaction and about programmers using it in their parts of kernel
code.
>
> > 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.
>
Yeah, you can not see the sense, because you can not imagine following:
there are backends - coding interfaces. You propose new coding
interface.
which would work for particular underlying metadata structure.
there are frontends - common code for talking to user. frontends read
metadata
structures, accroding to metadata read data structures.
Now, it all frontends and backends would use common metadata structures,
then that above would make sense.
>
> 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.
>
Yeah, this is kindof nice coding interface.
And underying data structure is nice,
exept that:
data pointer = data pointer
formatter function = metadata pointer
label = belongs to metadata structure.
So, instead of yours tuple (label,function,data):
there would be
struct kobject {
void * data;
struct kobject_metadata * metadata;
};
> OO is no magic bullet.
>
No , OO is a systematic way of thinking.
See above data structure.
It is about the same, just naming is different
mine is a bit more systematical and extentsible.
if metadata containers are resource-counted unique,
then it should be using less memory in data segment
even if label is not along with kobject, but in metadata.
And, module autoload would be easyer.
So all of difference is that it becomes a bit more systematic.
elmer.
PS: counting about 10 insults in you post, I feel need for answering
with at least one: you are bad, bad, bad, miserable, ugly, terrible.
-
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:13 EST