On Fri, 09 Jul 1999, Alexander_Maryanchick%STORACTIVE@storactive.com
wrote: > There were some questions about my message.
> I took the liberty to combine them to reduce email traffic.
> My apologies if you are offended.
I'll follow your lead.
> >> 2. Why in the kernel?
> > Why does the kernel necessarily help?
> The problem of userspace realizations is that
> a. thay can not store resources together with data.
Someone already said, yes they can. Please give me an example where you
can't. What's your definition of a resource? Information about the
data? That's easily and commonly stored with the data.
> b. thay must index files by full names.
Like the other respondant, I don't understand what you mean.
> >> a. *Huge* perfomance losses (10 - 1000%)
> > This point is not defended very well:
> - scanning /etc/magic for 1000 files in directory is *seconds*.
for i in 1 2 3 4 5 6 7 8 9 a; do
for j in 1 2 3 4 5 6 7 8 9 a; do
for k in 1 2 3 4 5 6 7 8 9 a; do
/usr/games/fortune >$i$j$k
done
done
done
time file * /dev/null
0.82user 0.06system 0:00.92elapsed 95%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1146major+176minor)pagefaults 0swaps
Doesn't look like "seconds" to me. Looks like less than a second.
This also doesn't mean the 'file' could not be optimized.
> - parsing extensions (DOS sort of metadata) is milliseconds.
This isn't the "Unix way." I don't think anyone will argue with this.
I don't think this is an acceptable alternative.
> - following @albod/type is microseconds.
I'd like to see some evidence. How is the kernel going to store this
resource data? How much data do you personally think is going to be
put in resources if they were available? I think it could be rather
large and end up being many times the size of the data itself. Does
the kernel store the resource in the same "file" as the data? If so,
how is this different than a user space program storing it just like
they do now? If not, where oh where would the kernel store it? Will
there be a percentage of every filesystem reserved for resources? How
much will this be? What happens when that space runs out? Does the
kernel dynamically allocate this storage for resources? Doesn't sound
like this would be "microseconds" to me.
And how to represent type? Is the kernel supposed to have some
registry that maps a type number to a name? Are you saying store
actual text as the type? Who makes the determination of what the
standard number of name for a given type is? Is there going to be a
standards body created that approves new types? Are we going to shove
this on the IANA? Sounds rediculous, but we are talking about puting
resources in files that will be transferred over the Internet. There
has to be some standard format and protocol for transferring such
files. Otherwise, they resources will only be on your Linux box and
you could never share data with others.
A simple suggestion - take this through the standards process before
implementing it in Linux. Or, at least do a complete write up so that
we can see exactly how you are proposing to do what you want with
resources. It's not like you have to get MY approval. I haven't as of
yet contributed one line as a kernel developer. But from an outsider's
viewpoint I think there would be MUCH less controversy and much more
agreement if there was a complete white paper write up of what is being
proposed.
This is not some simple addition to the kernel that someone could
simply send a patch in for and be done with it. It needs to be
architected before implementation. Obfuscating the kernel - Just Say
No.
If it is eventually integrated into the kernel PLEASE make it an option
so that people can turn it off.
> >> - create cache database (it will duplicate file names
> >> => waste disk space)
> > Hmm I already give 128MB to my swapspace.
> > Why not not use a little of that?
> To give 50 Mb for 'file types' cache only???
> IMHO it's much uglier than fixing findutils.
Well, as mentioned earlier where the hell is the kernel going to store
the resources. If it's in traditional files then there is no need for
the kernel to get involved. If it's in some special area of the
filesystem, then I think you're going to need much more than 50Mb for
all this resource crap given the size of today's hard drives.
> >> b. Security holes
> >> ACLs in tarball?
> > This is a good point. However, it may be solvable with a much simpler
> > kernel mechanism.
> a. What is simpler: one powerful mechanism or 100 simple mechanisms?
You seem to want to force everyone to use one complex mechanism that
may not fit everyone's needs. I'd much rather see app developers have
the freedom to do what they want. Sure, they could ignore the resource
fork stuff even if it is included in the kernel and do things in the
"traditional" way. But, just having that "one powerful mechanism" will
unduly effect their performance.
> b. What simpler kernel mechanism?
> If you store somewhere additional data - you must rewrite mv, aren't you?
Earlier you said that userspace programs could not handle this concept.
Now you are complaining that mv would have to be rewritten if you
DON'T (as in DO NOT) put resource fork capabilities in the kernel?
It's the exact opposite. If you have userspace programs handle the
compund document, resource forks, whatever you want to call them, then
the file will be a "standard file" as far as mv, tar, ftp, etc are
concerned. If you put compound document, resource forks, or whatever
you want to call them facilities into the kernel THEN you would have to
rewrite mv, tar, ftp, etc OR come up with totally new transfer and
storage protocols AND have to get everyone else in the world who
communicates on the Internet to agree to your new standards AND write
new programs to handle these new protocols to replace mv, tar, ftp, etc.
>> I honestly can't believe that this is going on for so long. I don't
> > think applications are already too slow. What applications?
> Personally I am not satisfied with file managers perfomance.
> 'DOS Navigator' is 1000 times faster than kfm determines file types.
> (DOS uses file extensions)
I don't know 'DOS Navigator.' Is it a graphical application? kfm is.
Does it run under a structured window system like X or MSWindows or
does it have it's own custom made GUI? Does it support drag and drop
and all the other things that kfm does?
For some reason I don't think this is a "fair" comparison. If you want
to use a DOS like file manager I think there are a handful available
that run quite well in an XTerm - try mc.
> > I don't see any problems with the current way of doing things.
> You are lucky! But some of us use sluggish file managers, etc. :-(
Then pick a different file manager! Don't mess around with the kernel
just because you don't like the standard file manager for your window
system. Or lend a hand to make kfm faster. I do believe that the
source is available :-)
> > parsing conf files is slow? Where'd anybody get that idea from.
> I did not benchmarks: I only yawned and listened to the HDD.
May be you need a new hard drive :-)
> > How often do you parse conf files?
> a. Initialization of * program.
> For comparison: BeOS starts (with full GUI) in 6 seconds.
Then use BeOS
The only program that takes a little too long for my taste is Netscape
Navigator. I'd attribute this to feature creep and a horrible code
base more than because the kernel doesn't handle resource forks. I
understand that Mozilla is turning out to be quite fast indeed!
> b. loading xpms.
Er, this may be a not-good file format. Why not store the data in a
binary format? I don't think that your dislike of the pixmap format
standard for X is a good reason to mess with the kernel.
Write a new standard.
> c. logging dynamic data.
Don't have a clue what you mean here.
Cheers,
Fred
-
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/