linux-kernel - Re: [GIT PATCH] UIO patches for 2.6.21

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: <200704281549.29572.hjk@linutronix.de>
Date:	Sat, 28 Apr 2007 15:49:28 +0200
From:	Hans-Jürgen Koch <hjk@...utronix.de>
To:	Matthieu CASTET <castet.matthieu@...e.fr>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [GIT PATCH] UIO patches for 2.6.21

Am Samstag 28 April 2007 15:00 schrieb Matthieu CASTET:
>
> uio_dummy.c (that should be present according documentation) seems
> missing.

Well, uio_dummy was created during development to have something to
test with. It calls uio_event_notify() from a timer routine to 
simulate interrupts without having a real hardware device.

Besides that, uio_dummy has no real use. It might or might not be
useful to put it in mainline. IMHO, we should include it because
it shows ow UIO works and gives developers the possibility to test
at least parts of their userspace code without having the real hardware
(e.g. on their laptop).

>
> I find the doc not very clear for the devices where there is no
> interrupt : they speak of some kernel timer, but a userspace timer could
> be used (and even the userspace driver could be written without kernel
> support at all).

I'm afraid the doc too much emphasizes that timer. The reason was probably
that I worked with uio_dummy at the time I wrote the doc. Fact is that you
will rarely use a timer to generate interrupts. The only application I can
think of is something where you want to poll a device, say, every 10msec.
Then it might sometimes be the simplest solution to do it that way. But even
then there are probably userspace-only solutions most of the time.

But in general you're right, if a device doesn't generate hardware 
interrupts, you don't need UIO.

>
> At the end of the doc there is something about IRQ_HANDLED vs IRQ_NONE.
> Last time I check kernel irq code, in both case next irq handler are
> called. The only difference was that if all handler reply IRQ_NONE, the
> kernel gave an error about an unexpected interrupt.

It works like any other driver that handles interrupts. If you want to
support shared interrupts, your handler needs to be able to find out 
whether its device caused the interrupt or something else. You return
IRQ_HANDLED in the first case and IRQ_NONE in the second. If an interrupt
occurs and there's no driver that handles it, then the kernel has every
right to complain. Whoever enabled the interrupt must also be able to
handle it. That's one of the reasons why we need a kernel module to
handle interrupts, you can't do that from userspace.

>
> Also why sysfs is used for describing the mapping instead of something
> like an ioctl ?

Introducing new ioctls is ugly.

> UIO could be useful in embedded system where sysfs is not always
> desirable.

I see your point. But we need to make some information available for
userspace, in a standardized way. It was a design decision, and I still
find it quite good.

Thanks,
Hans

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