November 2001 - Darwin-kernel

Re: Modifying Bundle's Info Property List
by Stéphane Sudre 21 Nov '01

21 Nov '01

On mercredi, novembre 21, 2001, at 04:33 , Sean Morrell wrote: I don't know which conference these questions are best suited. Please tell me if this message needs to be redirected. I'm using the Core Foundation Bundle services to obtain the information property list for a driver bundle using the routine CFBundleGetInfoDictionary. However this routine returns an immutable reference and I need to modify this information property list. How can I modify the information property list for the bundle? CFMutableDictionaryRef CFDictionaryCreateMutableCopy(CFAllocatorRef allocator, CFIndex capacity, CFDictionaryRef theDict); For more information, you can have a look at the CFDictionary.h header. Also since the bundle is a driver and will reside in /System/Library/Extensions, will I have a file access issue? Wouldn't it be possible to add it to the /Library/Extensions folder instead ? (I don't know if it would work). The property list is being modified from a system preference pane in user space. How do I get the necessary access? With the Security Framework.

1 0

Re: User / Kernel
by David A. Gatwood 21 Nov '01

21 Nov '01

On Tue, 20 Nov 2001, Sean Morrell wrote: > Actually, the driver is for an audio device. And the user space > application is nothing more than a system preference pane, needed only to > configure the device. The audio device has some pecularities making it > unconfigurable using the typical CoreAudio interface. I do have the > option of using an Audio HAL Plug-In. But I just wanted to see if another > IPC method might quicken the development. At this time, I simply need a > one way notification to the driver. Eventually the driver will need to > respond to the preference pane, returning small structures of data. In > both cases, what IPC would you recommend? I'd probably just throw a sysctl at it, make it a SYSCTL_PROC so that it calls a routine in the driver that stores the value. You can also use the same mechanism to read back the values the driver is currently using. Should work pretty well for tuning small parameters in a driver or other parts of the kernel. Also has the advantage of being a pretty standard BSD-ism. Later, David --------------------------------------------------------------------- Check out my weekly web comic: http://www.techmagazine.org

1 0

Modifying Bundle's Info Property List
by Sean Morrell 21 Nov '01

21 Nov '01

I don't know which conference these questions are best suited. Please tell me if this message needs to be redirected. I'm using the Core Foundation Bundle services to obtain the information property list for a driver bundle using the routine CFBundleGetInfoDictionary. However this routine returns an immutable reference and I need to modify this information property list. How can I modify the information property list for the bundle? Also since the bundle is a driver and will reside in /System/Library/Extensions, will I have a file access issue? The property list is being modified from a system preference pane in user space. How do I get the necessary access? Thanks, Sean

1 0

Re: User / Kernel
by Sean Morrell 21 Nov '01

21 Nov '01

dgatwood(a)gatwood.net writes: >On Tue, 20 Nov 2001, Sean Morrell wrote: > >> What forms of IPC can be used for communicating between a user >application >> and a device driver? > >Well, lots of stuff. That's kind of a broad question. You could use a >sysctl, RPC, an ioctl, good old raw Mach IPC (ick).... It really depends >on what you're trying to do. Are you writing a driver whose client is >primarily in user space, or are you writing a driver for which you simply >want to tune run-time parameters from user space? > >If you are just trying to tune parameters, I'd think you'd probably be >best served by just adding a BSD sysctl or possibly an ioctl. > >If, however, the primary client is in user space, you should look into the >way user clients/device interfaces are being done in other areas and >consider adopting that design. > >Also, if your primary client is in user space, you should also consider >writing your driver entirely in user space, rather than putting it in the >kernel, then using sockets or posix shared memory or pipes to communicate >with the driver. > >So again, what is it you're trying to do? :-) Actually, the driver is for an audio device. And the user space application is nothing more than a system preference pane, needed only to configure the device. The audio device has some pecularities making it unconfigurable using the typical CoreAudio interface. I do have the option of using an Audio HAL Plug-In. But I just wanted to see if another IPC method might quicken the development. At this time, I simply need a one way notification to the driver. Eventually the driver will need to respond to the preference pane, returning small structures of data. In both cases, what IPC would you recommend? Thanks, Sean > > > >Later, >David > >--------------------------------------------------------------------- > Check out my weekly web comic: > http://www.techmagazine.org

1 0

Re: User / Kernel
by David A. Gatwood 20 Nov '01

20 Nov '01

On Tue, 20 Nov 2001, Sean Morrell wrote: > What forms of IPC can be used for communicating between a user application > and a device driver? Well, lots of stuff. That's kind of a broad question. You could use a sysctl, RPC, an ioctl, good old raw Mach IPC (ick).... It really depends on what you're trying to do. Are you writing a driver whose client is primarily in user space, or are you writing a driver for which you simply want to tune run-time parameters from user space? If you are just trying to tune parameters, I'd think you'd probably be best served by just adding a BSD sysctl or possibly an ioctl. If, however, the primary client is in user space, you should look into the way user clients/device interfaces are being done in other areas and consider adopting that design. Also, if your primary client is in user space, you should also consider writing your driver entirely in user space, rather than putting it in the kernel, then using sockets or posix shared memory or pipes to communicate with the driver. So again, what is it you're trying to do? :-) Later, David --------------------------------------------------------------------- Check out my weekly web comic: http://www.techmagazine.org

1 0

User / Kernel
by Sean Morrell 20 Nov '01

20 Nov '01

What forms of IPC can be used for communicating between a user application and a device driver? Thanks, Sean

1 0

Re: What is the preferred visual notification method from a daemon?
by Kevin Van Vechten 20 Nov '01

20 Nov '01

Hello Kevin, There are a couple choices here, which I think differ depending on whether your daemon will run on Darwin or Mac OS X. For Darwin, you should investigate the user notification library, Libunc (cvs path is /Libraries/Apple/UserNotification/) though I'm not really sure what options there are given that Darwin doesn't have a GUI. The darwin-userlevel list is a good place to talk about Libunc. For Mac OS X, you should take a look at CFUserNotification.h which probably does everything need, but that's better discussed on a different mailing list. Also I think everything you need is in the user level, so you probably don't need the darwin-kernel list for this one. -Kevin Van Vechten On Monday, November 19, 2001, at 02:04 AM, Kevin Bohan wrote: Hi, I am writing daemon that shuts down the system in response to an external event. The shutdown is performed by a daemon process. I don't really have a UI for this app, except for a pref pane to configure settings. I would like the user to be "notified" prior to shutdown. By notify, I mean a visual notification message/dialog pop-up, whatever. As I daemon I know I cannot directly show any UI elements. What is the preferred method of displaying a user-notification in this case. Kirby _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ darwin-kernel mailing list darwin-kernel(a)lists.apple.com http://www.lists.apple.com/mailman/listinfo/darwin-kernel

1 0

Re: How to determime process name from pid?
by justin＠mac.com 20 Nov '01

20 Nov '01

Look at code for 'ps' or 'lsof'. Regards, Justin On Monday, November 19, 2001, at 06:33 , Kevin Bohan wrote: If I have a PID is there a way (not is a shell script, but in C code) to determine what the name of the process whose PID this is, if there is a process with this PID. Kirby _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ darwin-kernel mailing list darwin-kernel(a)lists.apple.com http://www.lists.apple.com/mailman/listinfo/darwin-kernel --- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | If you're not confused, | You're not paying attention *--------------------------------------*-------------------------------*

1 0

Re: devfs user client, RFC
by Kevin Van Vechten 20 Nov '01

20 Nov '01

On Thursday, November 15, 2001, at 10:23 AM, Godfrey van der Linden wrote: The problem we are trying to solve is to get open/read/write/ioctl/close access to a /dev/... file. With the current implementation that means talking to a full on cdevsw entry, 'cause there is just no other alternative. This morning a thought occurred to me, I propose we change Libc syscall implemetation to redirect the read/write/ioctl/close calls selected by fd. Sounds interesting. I was scared of this when I first read it, but now after I've thought about it a while it seems like the most reasonable solution. Only the open goes directly into the kernel. Then we make the other cdevsw calls indirect through a pointer to a function in user land BEFORE taking the syscall trap. This solves all sorts of problems with getting data from process to process. The redirector will call functions that implement read/write/ioctl (RWI) on top of the CFPlugIn model proposed by ChrisS. Remember the the CFPlugIn interface to tapes and CD etc will already exist as that is MacOSXs preferred solution for device access of this nature. Taking this idea, here's how I imagine things: We'd need an IOKit extension to provide the devfs creation API. Some application, for example a userland tape driver, would call the creation routine, and specify the path to a client CFPlugin to handle calls to the dev node. The IOKit extension would maintain a lookup table of dev nodes and CFPlugin Paths. During an 'open' call, Libc would query the IOKit extension to see if the returned fd is special or not. If it is special, the CFPlugin associated with it would be loaded (or retained) into the client app's address space. The future read/write/ioctl calls would be forwarded to functions in the CFPlugin, which would then do something... for example communicate with a userland tape driver via mach messages. For a 'close' call, the CFPlugin would be released. Cons: Requires a small lookup-table that is wired into memory. Pros: Doesn't require a general devfs daemon, doesn't require buffers taking a detour though kernel space. Also seems to address many denial of service or other related concerns, since each plugin would live in the clients' address space, and there's no central "userland devfs hub" that might be killed. Is this what you had in mind? -Kevin

1 0

Re: How to determime process name from pid?
by Umesh Vaishampayan 19 Nov '01

19 Nov '01

Moved to "darwin-userlevel(a)lists.apple.com". On Monday, November 19, 2001, at 06:33 AM, Kevin Bohan wrote: If I have a PID is there a way (not is a shell script, but in C code) to determine what the name of the process whose PID this is, if there is a process with this PID. Kirby What do you plan to do with the name? Look at "ps" sources to see how it does it.... --Umesh -- Umesh Vaishampayan Apple Computer, Inc. Mac OS X Kernel Ph: (408) 974 0229

1 0