Messages in this thread | | | Date | Thu, 30 Apr 1998 21:46:13 -0400 (EDT) | From | James Mastros <> | Subject | Re: 2.1/2.2: a.out question |
| |
On Thu, 30 Apr 1998, Michael Elizabeth Chastain wrote: > Hi guys, [...] > Someone should take a look at fs/exec.c, at the top, where it > registers the binfmts. The registered binfmts go into a linked list > and new ones are registered at the *front* of the list. We could get > a performance improvement by changing either the declaration order > in binfmt_setup, or the list code in register_binfmt. > > I think it would be better to change register_binfmt to add new entries > to the tail of the list, so that rarely-used formats that come from > modules would not be at the front of the list. On the other hand, if > we keep the same list ordering but invert the order in binfmt_setup, > then more recently registered formats continue to get checked in front > of older formats, which may be important semantically. I would think that it would be -- we want a module to be able to override a compiled-in format (so, for example, we can write a binfmt that overides a binfmt that is buggy in a pirtuclar case such that it thinks that it can handle an executable that it really can't). This patch just changes the registration order to java, a.out, a.out32, elf, elf32, em86 and then misc -- I think that this keeps all important semantics, sombody please correct me if I am wrong.
> I don't have time to write a patch for this, though. I do. It's attached under my normal disclaimer: I havn't tested this, but's it's simple enought that it would take extreme idioticy to screw it up. I have been known to have moments of extreme idiotcy. (BTW -- My last patch produces a self-rebooting kernel (right after "Ok, booting the kernel") in the CONFIG_NET=y, CONFIG_INET undefined case -- any ideas? Sigh -- It's still better then a compile error, IMHO.)
-=- James Mastros
-- True mastery is knowing enough to bullshit the rest. -=- Me
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |