>>>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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/