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.
Some might wonder why I want this information from a driver. Well, here
goes:
1) u_comm is required so that I can trigger different behavior for
different applications. Basically I have to deal with buggy
applications, that are preexisting. In order to tell whether an
application is a "mixer panel" or a "regular audio client" I have to
rely on the application to self-identify with certain ioctls. But
legacy applications don't do this, and (ab)use other legacy ioctls with
old-style audio semantics. By looking at u_comm, I can identify
applications that should have self identified (the gnome mixer panel and
volume controls for one!) and give them the correct semantics. (In this
case, their use of AUDIO_SETINFO should go to the real hardware to
affect system-wide settings instead of only applying to a virtual
channel for the application itself.)
2) u_psargs is required to implement properly the OSS API that we
"inherit" from Linux. Basically, applications (such as mixer panel
applications) expect to be able to know what command is using a virtual
channel. While there are other ways to do this in userland in Solaris
(ddi_get_pid() followed by use of ps(1) or procfs), the applications are
coded to the Linux API where the command name is returned in an ioctl
back from the driver. It is a significant goal to enable multimedia
applications that we don't require them to alter their code to run on
our stuff.
So what I have works for me for now. And as long as the drivers are
bundled, or the thread, proc, and user structures don't change
(unlikely!), I'm fine. But a clean DDI interface would be vastly
preferable. Kernel folks, what do you think? Can we do this? I'm
thinking like:
const char *
ddi_get_command(void)
{
return (ttoproc(curthread) ? PTOU(ttoproc(curthread))->u_comm : NULL);
}
const char *
ddi_get_psargs(void)
{
return (ttoproc(curthread) ? PTOU(ttoproc(curthread))->u_psargs : NULL);
}
Thanks.
-- Garrett
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
