Re: On re-working the major/minor system

["H. Peter Anvin" <hpa@zytor.com>]

Alan Cox wrote:

>>>That works, and should prevent most major problems.  Hmm.  At
>>>least for cpio there are 6 chars worth of device info in there,
>>>so we coule easily go to 48 bits without RPM problems.  Or redhat
>>>could fix rpm to use tarballs like debs do, and then we could go
>>>
> 
> RPM can't easily use tarballs. Too much of a tar ball isnt rigidly defined so
> you can cryptographically sign it.
> 


Why does that matter?  You're signing a *specific instance* of tar, not 
the generic format.


> 
>>>to 64 bit devices no problem.
>>>
>>The big stubling block seems to be NFSv2.
> 
> Well 2.5 isnt going to be able to support NFS without a magic daemon
> maintained translation table - so that when the kernel randomly changes the
> major/minor number of an exported file system (eg a USB reconnect or even plain
> boring shutdown/reboot) it can keep consistent file handles.
> 
> If you have a file handle table surely you can remap every NFS file handle
> through that down to 32bits. For device files the problem doesn't matter 
> because at the kernel meeting Linus said those were going to change in a way
> that meant devices over NFS are a lost cause and clients would have to use
> devfs
> 


Yeah, I know what Linus said at the kernel summit.  As far as I could 
tell he rejected anything that seemed like a sensible approach from here 
to there, but that's just my $0.02...

	-hpa