>> Well it can't be any worse than the current crap. At least it'd
>> stand a chance in hell of scaling a little bit. So I took a very
>> quick look ... what syscalls are you reduced to per pid, one ioctl
>> and one read?
>
> Oh, yes it can. Easily.
> * device is not network-transparent - even in principle
Is that really a major issue for ps?
> * restricting data access would be harder - welcome to suid or
> sgid country
I can live with that level of pain if my benchmark doesn't get
driven into the wall by the tools that are meant to be montoring
it ...
I'm sure there are bigger rocks to be thrown at it as well, and
ugly critters to be found under those rocks, but I don't see anything
insurmountable here yet. Whereas opening billions of files is just
unworkable.
Better still, you seem like an excellent candidate to propose a good
design that's efficient and workable?
> * real killer: you think Albert would fail to produce equally
> crappy code and equally crappy behaviour? Yeah, right.
Heh ;-)
A hostile takeover might suffice here, if necessary ...
M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Nov 07 2002 - 22:00:36 EST