[PATCH] Add support for mounting by label or UUID

[Rob Landley]

On Tuesday 13 June 2006 10:37 am, Jason Schoon wrote:
> On 6/13/06, Rob Landley <rob at landley.net> wrote:
> > On Tuesday 13 June 2006 3:17 am, Jason Schoon wrote:
> > > An updated patch is attached.  Should work the same as previously,
> > > except I added support for FAT file systems as well.  Turns out I
> > > needed to support them, and since the util-linux mount didn't handle
> > > them, it was time to brush up on my FAT skills ;-)
> > >
> > > I have now tested this with Reiser, ext2, ext3, FAT16 and FAT32 on a
> > > x86 platform.  Feel free to test on others and let me know if there are
> > > issues.
> >
> > Ok, I just read through this, and I'd really rather not glue it onto
> > mount.
> >
> > This is already more or less a separate applet that finds which partition
> > has a given disklabel, so why not just make a new applet that does that
> > and call mount via something like:
> >
> > mount `finddisk label=blah` /thingy
> >
> > Does that make sense?  (You could also add CONFIG_FEATURE options to that
> > for supporting the various filesystem types.)
> >
> > On a side note, don't we _have_ fat and ext2 headers already defined
> > somewhere?  (That part can be cleaned up later...)
>
> I actually considered doing just such a thing.  Similar to the findfs
> utility that already exists in e2fsprogs.  In my particular case, I
> have people wanting to use it directly from mount who are used to
> having it in the full mount, so I didn't go down the seperate utility
> path.

The separate utility is worth checking in (because people can always disable 
it), and then giving mount an option to use that functionality if it's 
already there makes sense (it's just a UI tweak, not really a significant new 
code addition).

But adding a large pile of code that's only accessable as a wart hanging off 
the side of mount makes me wince.  Perhaps this is psychological, but it just 
doesn't seem like a good thing design-wise.

> I also considered adding configuration of the various filesystem
> support, likely buried under CONFIG_NITPICK.  I wasn't sure though if
> the small amount of overhead over the required general support was
> worthy of a bunch of config options.

It's partly that we currently haven't got _any_ reiserfs support, and I'm 
looking at this and going "Oh no, somebody's going to want to add mkreiserfs 
and friends to busybox.  I really don't want to go there."

This is exactly the sort of thing CONFIG_NITPICK is for, by the way. :)

> Yes, on the headers.  I was trying to make it self-contained first.
> Going back and trimming out the duplicated header code would be a good
> second-pass to make at it.

Yes please.  (This was submitted before the deadline, so extra massaging to 
get it into mergeable shape doesn't bother me.  As long as the feature creep 
has clear boundaries, I'll live. :)

Rob
-- 
Never bet against the cheap plastic solution.