re: Problem with syscall_disestablish() - PR kern/50430

[Paul Goyette <paul%vps1.whooppee.com@localhost>]

> > I agree that it probably needs to be completely re-written if it were
> > to be generally useable.  But, given that the only real use-case we
> > have for it so far is make(1) (and even then, only in "meta-mode"), I
> > think that the re-write effort far out-weighs the benefits.
>
> right, i agree.
>
> it's still not useful for mips64 platforms today -- since those
> default to 32 bit binaries on 64 bit kernel.
>
> same with running 32 bit chroot builds on i386.

Yes, that would definitely be a problem with the currnt implementation.

> > Besides, I don't know enough about the vfs layer to get it right!  :)
>
> not too late to learn :-)

Well, the US tax people seem to think I've still got a few more years
left, so maybe I'll take a look.  :)

One more issue with the current mechanism:  what happens if we have
"something else" arrive that also wants to hijack syscalls?  I can see
all sorts of potential confusion, depending on how much overlap there
is in the set-of-syscalls-to-hijack and on which code loads/unloads
first...  :(

I'm tempted to implement a syscall_{hijack,restore}() capability,
similar to syscall_{,dis}establish(), but I'm afraid that would just
encourage more bad behavior!

:)



+------------------+--------------------------+-------------------------+
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:       |
| (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com    |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org  |
+------------------+--------------------------+-------------------------+