mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Tom Spink" <tspink@gmail.com>
To: "Thomas Gleixner" <tglx@linutronix.de>
Cc: "Greg KH" <gregkh@suse.de>, "Hans J. Koch" <hjk@linutronix.de>,
	"Uwe Kleine-K??nig" <Uwe.Kleine-Koenig@digi.com>,
	linux-kernel@vger.kernel.org,
	"Jan Altenberg" <jan.altenberg@linutronix.de>,
	"Magnus Damm" <magnus.damm@gmail.com>
Subject: Re: [PATCH 1/1] UIO: Add a write() function to enable/disable interrupts
Date: Sun, 25 May 2008 00:00:55 +0100	[thread overview]
Message-ID: <7b9198260805241600m7a1c8dcva6cb6b41a4d2bacb@mail.gmail.com> (raw)
In-Reply-To: <alpine.LFD.1.10.0805250036481.3295@apollo.tec.linutronix.de>

2008/5/24 Thomas Gleixner <tglx@linutronix.de>:
> On Sat, 24 May 2008, Tom Spink wrote:
>> 2008/5/24 Thomas Gleixner <tglx@linutronix.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.

<grin>

>
>> >    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 ?

Simpler implementation, simpler use and future-proofing (in the sense
that ->write is no longer tied to this operation)

>
>> > 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.

Fair enough :-) symmetry is good.  This is pretty much the response I
got from Hans.

> Thanks,
>
>        tglx

-- 
Tom Spink

  reply	other threads:[~2008-05-24 23:01 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-22 19:22 [PATCH 0/1] " Hans J. Koch
2008-05-22 19:26 ` [PATCH 1/1] " Hans J. Koch
2008-05-22 19:47   ` Tom Spink
2008-05-22 20:08     ` Hans J. Koch
2008-05-22 20:26       ` Tom Spink
2008-05-23  5:41         ` Uwe Kleine-König
2008-05-23  8:51           ` Hans J. Koch
2008-05-23 11:48           ` Tom Spink
2008-05-23 11:58             ` Uwe Kleine-König
2008-05-23 12:00               ` Tom Spink
2008-05-23 12:14                 ` Hans J. Koch
2008-05-23 12:20                   ` Tom Spink
2008-05-23 13:01                     ` Hans J. Koch
2008-05-23  5:55   ` Uwe Kleine-König
2008-05-23  8:44     ` Hans J. Koch
2008-05-23  9:10       ` Uwe Kleine-König
2008-05-23 10:03         ` Hans J. Koch
2008-05-23 10:56           ` Uwe Kleine-König
2008-05-23 11:55             ` Hans J. Koch
2008-05-23 12:03               ` Uwe Kleine-König
2008-05-23 18:36               ` Randy Dunlap
2008-05-23 22:49                 ` Hans-Jürgen Koch
2008-06-04  6:30                   ` Uwe Kleine-König
2008-06-04  7:05                     ` Thomas Gleixner
2008-05-23 20:44               ` Leon Woestenberg
2008-05-23 22:43                 ` Hans J. Koch
2008-05-24  0:02                   ` Leon Woestenberg
2008-05-24  4:43               ` Greg KH
2008-05-24 22:20                 ` Hans J. Koch
2008-05-24 22:22                 ` Thomas Gleixner
2008-05-24 22:34                   ` Tom Spink
2008-05-24 22:46                     ` Thomas Gleixner
2008-05-24 23:00                       ` Tom Spink [this message]
2008-05-27 17:55                   ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7b9198260805241600m7a1c8dcva6cb6b41a4d2bacb@mail.gmail.com \
    --to=tspink@gmail.com \
    --cc=Uwe.Kleine-Koenig@digi.com \
    --cc=gregkh@suse.de \
    --cc=hjk@linutronix.de \
    --cc=jan.altenberg@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®