Hi! On Mon, Oct 18, 1999 at 12:52:37AM +0200, Guido Flohr wrote: > But the kernel raises SIGSYS in cases where the caller lacks the > appropriate privileges. Not in the case of slb.c, where it's raised when you try to call Slbopen() or Slbclose() from supervisor mode, i.e. when you have "too high" priveleges. > 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... OK, I'm going to try tonight, you'll get the results tomorrow. > 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. Mhmm, what the libc has in its struct stat must not necessarily be what the kernel internally uses. See http://www.deja.com/=dnc/getdoc.xp?AN=431784880 for example: Linux 2.2 still uses a 16 bit short for dev_t, it is planned to up this to 32 or more bits in 2.4 (I don't know what the situation is on current 2.3 betas), but nonetheless glibc2 offers 64 bits for dev_t, independent from what is internally used. > You seldom do expansive calculations on device numbers, so performance > shouldn't be an issue. Well, but you get problems with kernel calls like Fxattr(), which currently return shorts for both dev fields, and as far as I can see, there're not enough reserved fields left to add to 64 bit values. And ugly hacks like putting only the upper 48 bits into two new fields don't seem a good idea to me. And it wouldn't be a really good idea, IMO, to have one part of the kernel/filesystems return 64 bit values, and others 16 bit values ... > > Vote against SPAM: http://www.politik-digital.de/spam/ > ^^^^^^^^^^^^^^^^^^ I did. :-) To be honest, I haven't recently checked whether this campaign is still running. But it seems it is, at least the main page is still online. Ciao Thomas -- 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/
Attachment:
pgpYSiQkiu90g.pgp
Description: PGP signature