Mail Archives: djgpp-workers/1997/12/23/08:02:10
At 11:14 AM 12/23/97 +0200, you wrote:
>MNT_MNTTAB was lifted from Unix header files. Some Unix-born
>program could expect that to be a compile-time string.
Rats. I'd still like to have it tho' -- how many of the unix-born programs
are being ported to djgpp? How hard is it to fix them?
>If the only reason is to allow adding filesystems with `addmntent',
>then does it really need to be a file? Why not keep it in memory
>while the program runs? Do we have any reasons to leave it there
>after the program exits?
My short version: Yes, It has to be shared, yes.
Long version: Basically what I'm experimenting with is a .dxe file that is
only loaded if the application tries to open it's mount point. For these
applications, the mnttab holds valuable information -- the module to load,
the mount point, and some configuration information. The mount point is
either a "special file", like /dev/ttyS or a "file system" (which djgpp is
not fully ready for). The configuration information is mostly so that a
single dxe file (like a serial port dxe) can provide access for different
files (eg, /dev/ttyS0 /dev/ttyS1 etc). A normal application would not
actually addmntent; rather it would just getmntent this information (via an
add-on library). The add-on library keeps in memory a copy of the table,
and an "open" handler to load the module iff neccessary. For the most
part, the application wouldn't know about the mntent family or /etc/mnttab
or even where the plugins are.
In a sense, I'm using slightly abusing the mnttab concept -- I'm really
creating a /etc/vfstab, but djgpp doesn't run a mount script at startup...
A confusion point for some djgpp users who are used to admin'ing unix is
that part of the /etc/mnttab is not a reflection of what the OS has already
made available, but what djgpp can make available to interested
applications. The loadable module is placed somewhere (maybe lib/plugins
?) and the configuration information is placed in the mnttab by a utility.
Or, in the case of a named fifo, by mkfifo. And this info needs to stay
pretty static across executions and reboots.
> It surely will have one effect that could
>surprise people: programs run after the file was created will see
>those fake filesystems which they probably cannot access.
Only programs that use mntent and not loadable fsexts. These will see
filesystems with bizarre fstypes that don't correspond to dos or unixish
things (ie, "PLUGIN", "FIFO" and whatever others add) --- but only if they
scan with getmntent.
Randy
randym AT acm DOT org
- Raw text -