On Mon, 18 Oct 2004 11:20:16 +0100, Alex Kiernan <alex.kiernan@gmail.com> wrote:
> On Fri, 15 Oct 2004 17:35:50 +0100, Alex Kiernan <alex.kiernan@gmail.com> wrote:
> 
> 
> > On Wed, 13 Oct 2004 14:43:51 +0100,
> > viro@parcelfarce.linux.theplanet.co.uk
> > <viro@parcelfarce.linux.theplanet.co.uk> wrote:
> > > On Wed, Oct 13, 2004 at 01:10:10PM +0100, Alex Kiernan wrote:
> > >
> > >
> > > > On Wed, 13 Oct 2004 12:06:29 +0100, Alex Kiernan <alex.kiernan@gmail.com> wrote:
> > > > > I've run into a bug in the UFS reading code (on Solaris x86 the
> > > > > major/minor numbers are in 2nd indirect offset not the first), so I've
> > > > > patched it & bugzilled it
> > > > > (http://bugzilla.kernel.org/show_bug.cgi?id=3475).
> > > > >
> > > > > But where do I go from here? There doesn't seem to be a maintainer for
> > > > > UFS so I can't send it there.
> > > > >
> > > >
> > > > After advice from Alan (thanks), here's the patch which addresses the
> > > > problem I'm seeing. Specifically it appears that on x86 Solaris stores
> > > > the major/minor device numbers in the 2nd indirect block, not the
> > > > first.
> > >
> > > 1) please, move old_encode_dev()/old_decode_dev() into your helper functions.
> >
> > Will do.
> >
> > > 2) we could do a bit better now that we have large dev_t.  What are complete
> > > rules for
> > >         a) Solaris userland dev_t => on-disk data
> > >         b) major/minor => Solaris userland dev_t
> > > on sparc and x86 Solaris?
> > >
> >
> > Assuming I've followed it right...
> >
> > The kernel dev_t has 14 major device bits, 18 minor device bits (with
> > the major as the most significant bits).
> >
> > On disk there are 32 bits stored in host byte order, the device is in
> > the [0] indirect offset on Sparc, [1] on x86.
> >
> > Looking at an individual entry, if the top 16 bits are clear or
> > 0xffff, then the bottom 16 bits are the device number, with 7 bits of
> > major (most significant), 8 bits of minor (and the most significant
> > bit unused). If the top 16 bits are some other pattern, the on disk
> > mapping is the same as the kernel mapping.
> >
> 
> Attached is code to implement the code move of old_decode_dev and
> support for large dev_t (Solaris' own handling of this seems to be
> dodgy in the extreme). I've checked Solaris x86/sparc w/ both types of
> dev_t encoding for reading. I haven't checked writing as the code to
> detect clean filesystems seems to be bust for Solaris UFS filesystems.
> I'll have a look at whats wrong w/ it when I've a bit more time.
> 

The same functionality again:

Fix handling of device inodes on Solaris x86 filesystems, add support
for large dev_t against Solaris UFS filesystems

but with the helper functions moved out of inline code.

-- 
Alex Kiernan