Re: [MiNT] New signal SIGPWR - Power failure (restart)

[Guido Flohr <gufl0000@stud.uni-sb.de>]

Hi,

On Mon, Oct 18, 1999 at 03:19:51PM +0200, Thomas Binder wrote:
> 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.

Hm, the glibc manual says:

- Macro: int SIGSYS
	Bad system call; that is to say, the instructio to trap to the
	operating system was executed, but the code number for the system
	call to perform was invalid.

"Translated" to Atarian this would mean: You have done a Dchroot but your
kernel does not yet know that call.  But the kernel will not raise a
signal but will return -ENOENT instead.  That's why I thought that SIGSYS
is really not needed for MiNT.

BTW, is it necessary to raise a signal when doing Slbopen/Slbclose from
supervisor mode?  Why don't you simply let the call fail with -EPERM?  I'm
a little bit afraid of apps catching the signal and maybe doing cleanup
operations in supervisor mode (or does the kernel switch back to user mode
for the signal handler?)

Anyway, I'm still not convinced that the kernel needs SIGSYS.  SIGPRIV
still looks more suitable to me.

> > 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.

Fine, many thanks.

> > 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.

Sure.  The rationale behind it was: The stat() function is currently
really slow, especially because of that
UTC/localtime-Unix/GEMDOS-Timestamp problem.  A decent file system will
handle timestamps in Unix format.  Therefore the filesystem had to
translate timestamps back from Unix to GEMDOS format, the kernel will pass
them to the libc and the libc will have to convert them back from GEMDOS
to Unix and change them from localtime to UTC (which is in fact the most
expansive operation).  Now, there is a way to pass the stat values
unmodified from the file system via the kernel to the libc and we actually
hope to really improve performance from that.

But why having the kernel and the libc share the same notion of a struct
stat?  Simply because it avoids *any* conversion by the libc if the kernel
supports the new call.  I currently do a:

	int retval = Fstat64 (fd, &statbuf, follow_links);
	if (retval == 0) {
		return 0;
	} else if (retval == -ENOSYS) {
		/* Emulate via Fxattr or Fattrib.  */
	} else {
		__set_erno (-retval);
	}

As opposed to:

	if (retval == 0) {
		statbuf.st_mode = (mode_t) kernelstatbuf.st_mode;
		statbuf.st_dev = (dev_t) kernelstatbuf.st_dev;
		...
	} else {
	...

You will admit that the first alternative looks by far more attractive.
Of course that's still not a good reason for 64 bit dev_t.  But for a
single-platform libc like the MiNTLib it really makes sense to share
struct stat between the kernel and the libc.

> > 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.

But it is also not a good idea to mix up MiNTLib functions with directly
trapping via the macros in osbind.h/mintbind.h.  The MiNTLib will hide
those conversions from the client programmer.  And btw, the lower 16 bits
are used in dev_t and the macros still work.

> 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 ...

Any better solution to make the file system stuff 64 bit clean?  If we
want to support huge files than off_t has to be 64 bits, that's already a
mixture (because read, write, lseek etc. still use 31 bits).  But any
better idea?  Furthermore, it works.  I've compiled a lot of programs with
the new sys/stat.h and I never had to change a single line of code.

> 
> > > 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.

Yes, it is still running.

Ciao

Guido
-- 
http://stud.uni-sb.de/~gufl0000/
mailto:gufl0000@stud.uni-sb.de