Hi Terry (and others!)
You seem to know a lot about the kernel (as you always expand on my
Cliff Notes versions of my answers). Can you give me any hints on
the device driver question I posted a few days ago. There was a
response, however I don't see how it applies for these reasons.
1. When the hardware (board) is inserted, but no kernel driver
there are no failures.
2. When the hardware is installed with the minimal kernel driver
the system locks. The minimal kernel driver only attaches some
resources.
3. When doing the full initialization of the device (which works
in NetBSD) there are also the SAME failures as doing no
initialization at all of the hardware (as seen in the samples posted).
4. The device driver does not use MBUFS at all.
Any ideas!?? :-)
Thanks much in advance!
Andy
On 15-Feb-02 Terry Lambert wrote:
Sansonetti Laurent wrote:
Hi hackers,
Is there a way to read user-land environ(7) table from the kernel for a
given process ?
Yes and no, or we'd already have implemented variant
symbolic links.
The problem is manifold:
1)The environment is pointed to by the environ **
pointer in the user process. The location of
the environ ** pointer is not well known.
2)The environ ** value may be overridden by the user
program entirely, so the pages where the data lives
aren't where the are expected, so a saved pointer
to envp *[] at execve time is not a workaround
3)The envrion ** is require by POSUCKS (sometimes
spelled POSIX), so getting rid of it and making
the getenv/setenv/putenv/unsetenv functions use
a multiplex system call is not an option that
maintains POSIX compliance.
4)It's hard to satisfy #2 and #3 and maintain binary
compatability; the gross way you could do this is
to save two copies of environ **, the real one at
startup, and the shadow one called environ **,
and then if the shadow does not match the real,
fall back to the historical behaviour. Synchornizing
means that you would need to know when the change
happens (not possible, unless you catch a write fault
and implicitly fix it up, like SVR4 does with page
zero pointer dereferences, unless you specifically
tune the kernel to fault fatally on them), or you
would have to reflect all kernel level changes into
the user space area shadow (expensive, but doable).
5)The execve() envp *[] passing is tricky, at best,
for a modified implementation, since you have to
read it back to pass it down. One option, which
fails POSIX again, is to pass the default in if
there is a NULL passed here, for an in kernel
implementation (actually, you don't have to pass
anything for the user environment, if the system
and group contain everything you care about).
6)You can also put the environ ** into user pages
(read only) that are also mapped into a pointer off
the proc structure (read/write), so that the kernel
changes are visible to user space. This makes it
so that environ ** is not writable, but it is OK
to read it, so a minimum number of changes are
required for system/group/user logical names.
I run with a variant of #6 on one of my machines; I use the
same page I use for the environ ** for the pid, gid, and
other data to make them zero kernel overhead for getpid,
getppid, getgid, etc. -- basically, any system call that
only reads a small fixed sized data value.
This still means that the environment is stored in the user
space process, but the current environ ** is always known
to the kernel, and if it needs to be modified, it takes a
system call.
It's pretty cool: it lets me set the environment variables
for processes from other processes, and everyone inherits
from init's environment (system logical name table), the
process group leader's (if they aren't the leader themselves:
group logical name table) and then themselves, in increasing
priority, on getenv().
But of course, it violates the writability of **environ,
which POSUCKS wants, but I don't care (on that machine,
signals default to restarting system calls so that my
user space threads library is incredibly light weight, and
getting the one-close-destroys-all-locks-even-for-other-opens
behaviour is non-default, too... you have to fcntl(F_POSIX)).
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
