> I think the best solution would be to extend fstab syntax so that > in "auto" fs, we can specify options for only one fs, but I think > this is somewhat complicated and will introduce incompatibility > in a basic file such as /etc/fstab. So I've finally fixed my fix > by extending mount.c capability, adding the ability to silently > remove some options for some FS's (namely, mode= for udf).
fstab idea is absolutely hideous (I know because I cherished it for some - long - time :) besides it involves nontrivial amount of parsing in kernel space. I did suggest it here a while back. mount hack is just what it is - hack. Just like current kernel hack to ignore i18n options for some fs (actually here I believe *all* filesystem must support these options but well ...) The right solution is to add support for external helper and query it for mount options for a given device/fstype. This external helper could also be used to - proivde real fstype detection instead of current "auto" or my fstype list hacks - do something sensible when device could not be mounted. the "please insert CD" dialog that windows pops up would be very useful for newbies as example. - if device polling is added (as some people om lkml keep suggesting) run arbitrary command on insertion. Like launching CD player e.g. I started to do it but was distracted by poerting supermount to 2.5 (as there appear to be demand) and making 2.5 run properly to be able to work with it :) Actually the code to speak with daemon can be directly taken from any user-level filesystem, LUFS as example. > > What do people think? As long as kernel team remains silent about anything I do - your hack looks like the simplest solution. -andrey
