Re: cdrtools-2.01a22 ready
> > star -tv < /tmp/cdev.tar.bz2
> > ...
> > 255 7000 crw-r--r-- 1 root/other Jan 5 22:06 2004 cdev
> >
> > AS you see, this is a tar archive that includes a character
> > special with major 255 and minor 7000.
Postulate. Restoring of device entries from another architecture was
never guaranteed to provide meaningful results for following reasons:
- different platform allocate different amount of bits for major and
minor numbers, e.g. SVR3 specification reserves for 7 and 8 bits
respectively, SVR4 (e.g. Solaris and IRIX) - for 14/18, HP-UX - for
8/24, OSF - 12/20;
- restoring of devices from another platform can have undesirable effect
(imagine world writable /dev/null from another platform to coincide with
your system disk) and treated with special consideration or be avoided;
First bullet above means that multi-platform achiever *might have
to*/should take into consideration differences between platforms and act
accordingly, at least warning user about possibly unexpected results,
optionally trying to note actual inconsistencies.
> > If you unpack this on a Linux-2.6 system using a "star" binary
> > that has been compiled on Linux-2.4, you will extract a character
> > special with minor 88 instead of minor 7000.
Yes. But the result is not guaranteed to be sane in *either* case. You
can't really complain about something being broken if it's not
guaranteed to be intact. The only thing which is quaranteed to be
meaningful for device entries is pack-unpack on *same* platform. And
this works perfectly in either combination. Compile "2.6 binary" and
pack-unpack devices under 2.4 kernel. Does it work? Yes! Compile "2.4
binary" and pack-unpack devices under 2.6 kernel. Does it work? Yes, as
long as you pack-unpack those created by Linux /etc/MAKEDEV. Is there
2.6-specific /etc/MAKEDEV? Not currently. Will there be one? Unlikely.
First extended namespace user is devpts, "memory-based" *file system*
and there are all reasons to believe it will remain "memory-based" file
systems' domain.
Note that I wrote "2.6 binary" and "2.4 binary" in quotes! Why? Because
there're *no* such things as "2.6" or "2.4" binaries! There're glibc 2.3
and glibc 2<3 ones! Linux 2.6 kernel does not actually require glibc 2.3
for operation. Nor does glibc 2.3 require Linux 2.6 kernel. glibc 2.3 is
required for 2.6 in some particular cases. This one is included:
restoring of device entries from *another* architecture [which in turn
has pure academic value in either case].
> > This proves that you cannot run binaries from Linux-2.4 on
> > Linux-2.6 correctly.
Once again, result is not guaranteed to be sane, the result is expected
to be unexpected and the only right thing to do is to make best of the
situation! That's what multi-platform programming is/should be about.
> Well, it proves that you cannot run _some_ binaries that were
> compiled under linux 2.4 on linux 2.6 correctly.
Linux 2.4 provided 8 bits for major and 8 bits - for minor numbers, 2.6
extends it to 12/20, but it does this in backward compatible way! Can
application developers *deny* the fact that Linux kernel 2.6 provides
larger device namespace? No, application developers should be aware of
it and should respect it. Can applications be modified to produce result
with makes most sense in current run-time environment? Absolutely yes.
Should they be? Multi-platform ones, yes.
Now note "2.6 extends device namespace in backward compatible way." Does
it? Yes! Yet programs using makedev will get broken? How come and when?
Is it kernel issue? No! It's glibc 2<3 bug, makedev macro in particular.
The macro should have been ((major&0xff)<<8)|(minor&0xff). What should
glibc 2.3 archiver do to make best of situation and be runnable under
both 2.6 and 2.4 kernels? It should modify device verification procedure
and mask 16 least significant bits, when st_rdev doesn't match, e.g. 'if
(s.st_rdev != makedev(a,b) && s.st_rdev != (makedev(a,b)&0xFFFF)
verification_failed();' Can such archiver program be modified to be
compilable for glibc 2<3 and make best of run-time environment? Yes!
E.g. by redefining the makedev macro you at least can provide more
consistent over major device numbers. Of course modification procedure
has to be modified too.
To summarize. To make the program in question glibc 2<3 vs. glibc 2.3
aware *and* safe to execute under either Linux 2.4 and 2.6 kernels in
either combination, one could modify it as following.
1. *Whenever* minor number is to be used in makedev macro, it can be
screened as "if (makedev(2,0x100)==0x300) minor&=0xFF;" Note that this
operator doesn't have to be #ifdef __linux-ed or autodetected by a
configure procedure. Also note that "if" will most likely be optimized
away at compile time.
2. Whenever restored device number is to be verified, I would go for
dev_t devcompare;
...
devcompare = s.st_rdev ^ makedev(major,minor);
if (devcompare && devcompare&0xFFFF)
verification_failed();
Yes, minor has to be processed according to 1. somewhere in '...'. This
modification unfortunately has to be #ifdef __linux-ed.
Now back to the originating post. Usage of major macro in cdda2wav. Both
glibc 2<3 and 2.3 applications being executed under either 2.4 or 2.6
kernels are actually provided with *consistent* view over major numbers
for device entries created by /etc/MAKEDEV, such as those used with
cdda2wav. In other words "2.6 cdda2wav" is actually safe to run under
2.4. Well, as far as usage of major macro goes that is.
Oh! Almost forgot. My star 1.4.1 binaries, *both* "2.4" and "2.6" ones
go to endless loop consuming 100% of CPU time when I try to list
provided archive file. Cheers. A.
Reply to: