linux-kernel - Re: [PATCH 1/1] UIO: Add a write() function to enable/disable interrupts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.1.10.0805250036481.3295@apollo.tec.linutronix.de>
Date:	Sun, 25 May 2008 00:46:13 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Tom Spink <tspink@...il.com>
cc:	Greg KH <gregkh@...e.de>, "Hans J. Koch" <hjk@...utronix.de>,
	Uwe Kleine-K??nig <Uwe.Kleine-Koenig@...i.com>,
	linux-kernel@...r.kernel.org,
	Jan Altenberg <jan.altenberg@...utronix.de>,
	Magnus Damm <magnus.damm@...il.com>
Subject: Re: [PATCH 1/1] UIO: Add a write() function to enable/disable
 interrupts

On Sat, 24 May 2008, Tom Spink wrote:
> 2008/5/24 Thomas Gleixner <tglx@...utronix.de>:
> > It makes a certain amount of sense to use write. You hold the device
> > file descriptor anyway for the read (wait for interrupt) operation,
> > so using the same file descriptor is not a too bad idea:
> 
> What do you think about my ioctl idea, earlier in the thread?

I think it's a pretty bad idea.
 
> >    while (!stop) {
> >
> >        /* wait for interrupt */
> >        read(fd);
> >
> >        do_stuff();
> >
> >        /*reenable interrupt */
> >        write(fd);
> >    }
> 
> So, instead of write, you'd use ioctl(fd, ...).

And what's the actual gain ?

> > I thought about using a sysfs entry for a while, but looking at the
> > actual use case made the write() solution a more natural choice.
> 
> I thought ioctl would be more natural, as [en,dis]abling interrupts is
> a "controlling" operation :-)

Oh no. We are not going to open the bottomless pit of ioctls in
UIO. Once we have an ioctl channel in place we have the same mess
which we want to avoid in the first place.

Also when a driver needs more than the obvious interrupt wait /
control functions (which are pretty symetric btw.) aside of the
mmapped access to the device then it does not belong into the category
of an UIO driver.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/