Re: Is shared memory now only for use by the kernel in 2.3.x????

From: Ricky Beam (jfbeam@bluetopia.net)
Date: Sat Apr 29 2000 - 15:00:37 EST


On Sat, 29 Apr 2000, Tigran Aivazian wrote:
>what is "figlet"? I know "fillet", "piglet" and even "aiglet" but not
>"figlet".

It's an ascii art text translator... find a search engine and enjoy. :-)

>> First, it requires one's kernel to have procfs enabled.
>
>which is enabled in 100%-epsilon of the cases (i.e. except some
>specialized/embedded systems where people try to save a few K by disabling
>such an important part of the kernel as /proc)

It's alot more than "a few K". And procfs isn't that important. (Or should
I say, it never was.)

I am, of course, an efficiency freak. The amount of CPU being expended with
all the bullshit text in /proc just rubs me the wrong way. I've been using
linux for a very long time -- I wish I'd've screamed loader back then.
(I grew up as an embeded programmer.)

>> Second, it requires the program (user) to have read access to /proc.
>
>No, that particular file is readable by all 0644.

You missed my point... the program has to be able to see the procfs. Not
every program runs in the wide-open world. Do you have a /proc tree in
your ftp chroot() environment?

>> Third, it requires a metric buttload of unnecessary shit-code in the
>> source to grok text intended for a human to glean a simple number from
>> the kernel.
>
>human-readable interfaces in /proc are the right thing to have. No point
>in arguing against or about it. (if it was wrong, Linus wouldn't put it
>there - trust him).

Ah grasshopper, Right (tm) and Wrong (tm) have nothing to do with it. The
kernel contains what ever Linus is in the mood to include. And he has the
perverse brain disease making him suceptable to the "text is better" myth.
(See above reference to efficiency. Additionally, there have been heated
 discussions suggesting text is easier to process, which is also a bald
 falsehood as is evident to anyone who's ever taught programming courses.)

>> The relatively undocumented shmctl() commands IPC_INFO and SHM_INFO can
>> retrieve this information properly.
>
>ok, that is fine - I am glad you found an alternative solution.

Of course, the direct kernel interface that is shmctl() can be replaced
by shit in glibc to grok /proc at any point in the future... (don't get me
started on glibc :-))

>> (Gez, are we going to start programming everything in prolog now?)
>
>PROLOG is quite irrelevant for this discussion.

No it's not (well, not intirely.) That was intended to be a crack at all
those misinformed children who think that sprintf()+scanf() are better than
write()+read(). Prolog doesn't do anything you don't teach it to do
(including "simple" math.)

I don't understand the directions Linus is taking... The nfs server gets
moved into the kernel; a freakin' http server gets moved into the kernel;
RARP gets pulled down to userspace; and the communication linkage between
kernel space and user space becomes 150% human readable standard US English
text. What's next, NLS retooled completely in esperanto?

I'll have to go back through my archives to find the mount(?) program Linus
included in his .sig once. Those days are f****n' gone.

--Ricky

-
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 30 2000 - 21:00:17 EST