Garrett D'Amore wrote:
> Right now, I have a driver (the audio subsystem I'm working on) which
> will ultimately want to be integrated into Nevada. But it wants to
> access some fields in the uarea of the process that opened the driver
> initially -- specifically the command and arguments.
>
> My code currently does this horribly non-DDI compliant method:
>
> if (ttoproc(curthread)) {
> bcopy(PTOU(ttoproc(curthread))->u_comm,
> c->c_command, sizeof (c->c_command));
> bcopy(PTOU(ttoproc(curthread))->u_psargs,
> c->c_psargs, sizeof (c->c_psargs));
> }
>
> (And of course, I also rely upon MAXCOM and PSARGSZ macros for sizing
> those fields in my driver's structure.)
>
> It would be really cool if we could get a DDI interface to these fields.
I don't think we should add this to the DDI it would only encourage
others to do similar nasty things.
IMO this type of thing SHOULD break if the kernel changes, as a big
heads up that there is a problem here. In fact I'd be tempted to put in
DEBUG build code to make sure it breaks if anything changes.
I'm also concerned that there could be an information leak across TX
labeled zones via the driver back to userland. Though I'm not sure how
this will play with audit device allocation anyway, so there may not be
an issue.
--
Darren J Moffat
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
