Re: linking binfmt_misc with mime-types
On Mon, Oct 04, 1999 at 12:26:18PM +0100, Edward Betts was heard to say:
> Could I clarify some stuff please?
>
> Are we proposing that all mime-types have binfmt_misc setup? Does that mean,
> the kernel will be able to `run' any file in mailcap? Is that what we really
> want?
I'm not; I just happened to use the JPEG example in my first mail because I
had the magic numbers lying around. On the other hand, you could certainly use
them for this. Personally, I don't like the idea: you'll never be able to keep
track of every possible file type, and unless you do it'll be way too
inconsistent -- eg, file A.jpg works, but A.tiff doesn't (kinda like Windows'
associations). Executable stuff should be stuff that's executable.. (although
I can see the reasons why being able to do this would be nice)
> Another question is are their mime-types for all the programs we might want to
> run in this way? The programs I can think of off-hand, are Java, DOS EXE, and
> Windows EXE, are there any others? If we go with the ability to run documents
> like images and so on, do we have all the mime-types? Are we going to have to
> invent new mime-types? Is that a bad thing to do?
The other things I was thinking of that we might want to enter were Zcode
(Zork and so on) and possibly files for some of the various video game emulators
(nestra, snes9x). I think there are mime-types for some of these (isn't
Java application/x-java-program? I think DOS EXE may be
application/x-msdos-executable or something..). Probably zcode and video game
RAMs don't have mime-types (do they even have magic numbers? Hm.)
> Some more questions. Is it possible to recognise an html file by a couple of
> magic numbers at the beginning? Most html starts <html> or <HTML>, but it is
> not certian that it will look like this. Another thought is the possiblilty of
> running perl scripts without the bang path, but then how would the shell tell
> it is a perl script.
'file' does a pretty good job of that, but it's probably tough to get it
right. However, it's worth noting that binfmt_misc can also recognize files
based on extension (can you say 'horrible hack'? :) )
> If we put loads of entries into binfmt_misc are we likely to fill some kernel
> data table? What happens if it overloads? Do we significantly affect the
> performance of the system? If the kernel is checking each file against a list
> of magic numbers will it take a long time to run a file? (Probably not the
> kernel is fast, and most files we will run will be ELF, which is probably
> checked first.)
I don't know. I'd imagine it's been tested up to at least 20 or 30 entries..
at any rate, I would've done that if I had written it :)
> This is not user independant is it? The system can not be set so that one user
> has support for running Java/JPEGs from the command line, and another does
> not?
Nope. It could be on the Hurd, I think. I'm still trying to get up to speed
on the structure there, though..
Daniel
--
Exhilaration is that feeling you get just after a great idea hits you,
and just before you realize what is wrong with it.
Reply to: