Re: Mutex, SMBUS, ACPI (Re: how to mutex'ify a device driver)
On Tue, Nov 28, 2000 at 02:30:50PM +0100, Dag-Erling Smorgrav wrote: > Nicolas Souchu <[EMAIL PROTECTED]> writes: > > What are kernel mutex? A new mechanism for spl replacement? Is it > > introduced with the new SMP? I found nothing in the mail archives... > > You mean you don't read -committers, -developers and -arch? I see... No, not recently. I know that's unacceptable and I could not remain silent anymore with this huge fault on my shoulders :) Before I got my new job, I was really busy and could not contribute at all. Now, things are changing as I have some time allocated for personnal open source projects. Nicholas -- Nicolas Souchu Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mutex, SMBUS, ACPI (Re: how to mutex'ify a device driver)
On 28-Nov-00 Dag-Erling Smorgrav wrote: > Nicolas Souchu <[EMAIL PROTECTED]> writes: > > What are kernel mutex? A new mechanism for spl replacement? Is it > > introduced with the new SMP? I found nothing in the mail archives... > > You mean you don't read -committers, -developers and -arch? Even if he did it's fairly easy to not read a mail that is important. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mutex, SMBUS, ACPI (Re: how to mutex'ify a device driver)
Nicolas Souchu <[EMAIL PROTECTED]> writes: > What are kernel mutex? A new mechanism for spl replacement? Is it > introduced with the new SMP? I found nothing in the mail archives... You mean you don't read -committers, -developers and -arch? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Mutex, SMBUS, ACPI (Re: how to mutex'ify a device driver)
On 23-Nov-00 Nicolas Souchu wrote: > On Wed, Nov 22, 2000 at 04:58:32PM -0800, Archie Cobbs wrote: >> As a relatively simple exercise in -current kernel programming, >> I'm planning to mutex'ify the ichsmb(4) device driver (this is >> a relatively simple driver that currently uses splhigh()). I'd >> appreciate some feedback if what I'm doing is the right thing. > > What are kernel mutex? A new mechanism for spl replacement? Is it > introduced with the new SMP? I found nothing in the mail archives... Yes, they are used to replace spl()'s. You can read the mutex(9) manpage in -current for details about how the mutexes work. Hopefully before too long I will be adding some stuff to the developer's handbook to explain how to use the mutexes in the kernel. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Mutex, SMBUS, ACPI (Re: how to mutex'ify a device driver)
On Wed, Nov 22, 2000 at 04:58:32PM -0800, Archie Cobbs wrote: > As a relatively simple exercise in -current kernel programming, > I'm planning to mutex'ify the ichsmb(4) device driver (this is > a relatively simple driver that currently uses splhigh()). I'd > appreciate some feedback if what I'm doing is the right thing. What are kernel mutex? A new mechanism for spl replacement? Is it introduced with the new SMP? I found nothing in the mail archives... > > The plan is to give each instance of the device a mutex. This > mutex will be grabbed by both the top level code (when programming > the chip to do something or reading the results) and the interrupt > code (when servicing an interrupt). Have you comments about smbus/iicbus? What would you add to the todo list of the framework? Did you participate to ACPI discussions? -- Nicolas Souchu Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: how to mutex'ify a device driver
On 23-Nov-00 Archie Cobbs wrote: > As a relatively simple exercise in -current kernel programming, > I'm planning to mutex'ify the ichsmb(4) device driver (this is > a relatively simple driver that currently uses splhigh()). I'd > appreciate some feedback if what I'm doing is the right thing. > > The plan is to give each instance of the device a mutex. This > mutex will be grabbed by both the top level code (when programming > the chip to do something or reading the results) and the interrupt > code (when servicing an interrupt). This should work. Sort of. You probably want to wait a bit until I commit my cdevsw wrapper patches and an MP safe version of the psm(4) driver which will help detail what has to happen. > So far so good.. but what I don't understand is what happens if > the interrupt thread has to block on the mutex? It seems like all > other devices sharing the same interrupt (and therefore thread) > could be indefinitely blocked from servicing their IRQ's. Or is > it just assumed that the top half will never hold the mutex for > a "long" time? It the interrupt thread blocks on the mutex, then yes, that IRQ will be blocked. However, mutexes are intended to be held for relatively short periods of time. For example, you can't sleep (SSLEEP) with a mutex, so if you are blocked, you won't be blocked for very long. Also, since interrupt threads run at a very high priority, it will run again as soon as the top half releases the mutex. > Thanks, > -Archie -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message