tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
re: Problem with syscall_disestablish() - PR kern/50430
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 |
+------------------+--------------------------+-------------------------+
Home |
Main Index |
Thread Index |
Old Index