On Saturday 17 September 2005 06:28, "Martin v. Löwis" wrote:
> D. Hazelton wrote:
> > This is a bogus argument. You're comparing the way a _binary_
> > executable works to the way an interpreted _text_ script works.
> > execve(), at least on my system, isn't capable of running a
> > script - if I want to do that from a program I have to tell
> > execve() that it's running /bin/sh and the script file is in the
> > parameter list.
>
> This being the linux-kernel list, I assume your system is Linux,
> no? Well, on Linux, execve *does* support script files. This is the
> whole point of my patch - I would not propose a kernel patch to
> improve this support if it weren't there in the first place.
This is news to me. The last time I handed execve() a script as a
paramter I had errors returned from execve() -- I must admit that
this was not on my current system and I had assumed that the behavior
would be consistent.
> > While I appreciate that the kernel is capable of performing
> > complex actions when execve runs into a file that is not an a.out
> > or elf binary I have yet to see a "binfmt script" option in the
> > kernel config files ever.
>
> It's not a config option because it is always enabled. See
> fs/binfmt_script.c for details. It wasn't integrated into the
> binfmt system until I made it so some ten years ago, though.
I haven't gotten into that section of the code yet. I've been slowly
working my way through the code from the drivers that seem to cause
strange behavior on my system and then up the tree from there.
> > On the other hand, there is the "binfmt_misc" option, which does
> > the work that you seem to be looking for and can, AFAIK, be set
> > to handle both ASCII and UTF-8 scripts. Why add the complexity to
> > the kernel when it's not needed?
>
> One shouldn't add complexity if its not needed. However, this patch
> does not add complexity. It is fairly trivial.
You are correct. It is fairly trivial. However my point still is valid
that the Kernel has the whole binfmt_misc system -- I will admit that
I have recently been shown numbers that show a noticeable difference
in the speed of a binary executed using the binfmt_misc system and
the binfmt_script system, but the fact remains that offering handling
for UTF8 and ASCII scripts directly in the kernel will likely lead to
at least one more patch in which the the full Unicode standard is
implemented.
That, and my point remains that the kernel should know absolutely
nothing about how to execute a text file - the kernel should return
an error to the extent of "I don't know what to do with this file" to
the shell that tries to execute it, and the shell can then check for
the sh_bang. I do admit that this change would break a lot of
existing code, so I'll leave the argument to the experts.
> Regards,
> Martin
DRH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |