[no subject]

Martin said, "every single signal is important, you cannot simply
sacrifice one...".  I cannot follow here.  From an application's point of
view - no matter how it interprets that particular signal number - it
doesn't matter at all if it gets killed by a SIGSYS or a SIGPWR.  Both
signals are fatal and both signals should not be caught except by init
(and I currently take care of init myself).  This change really wouldn't
impose new incompatibilities.

> > I haven't seen problems but they came.  The kernel didn't even boot
> > and I couldn't find out why.
> 
> Mind if I try again? I have gathered some experience now in debugging
> non-booting kernels ...

Go ahead, I don't mind.  But I'm a little bit in a hurry now because that
SIGPWR is one of the reasons why I can't release a new MiNTLib...

> On another topic (Frank told me to ask you): Why does struct stat
> use 64-bit-integers for dev and rdev? And why has Dsetkey() been changed
> to expect a 64-bit-integer instead of a drive number?

Honestly, I have proposed 64 bit types for those because the GNU libc has
64 bits for them, too, and if we follow we can avoid source
incompatibilities with new software.

AFAIK, the reason for choosing 64 bits for dev_t lies in the macros
(makedev and friends).  They currently cannot be extended but it may be
desirable in the future to extend them.

> Why would you need 64 bits for a device number? Even IRIX64 (that's
> 64-bit-IRIX, not IRIX 6.4) has 32-bit values for these in its
> 64-bit-filesystem structures (struct stat64). I really see no reason to
> provide such a large range for device numbers, but maybe I'm missing
> something?

We had a lot of discussions lately on how to retrieve information about
device special files.  I think additional 32 bits won't hurt, will they?
You seldom do expansive calculations on device numbers, so performance
shouldn't be an issue.

Ciao

Guido
> -- 
> Thomas Binder (Gryf @ IRCNet)  gryf@hrzpub.tu-darmstadt.de
> PGP-key available on request!  binder@rbg.informatik.tu-darmstadt.de
> Vote against SPAM:             http://www.politik-digital.de/spam/
  ^^^^^^^^^^^^^^^^^^ I did. :-)
-- 
http://stud.uni-sb.de/~gufl0000/
mailto:gufl0000@stud.uni-sb.de