linux-kernel - Re: [PATCH 01/18] lirc core device driver infrastructure

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: <20080912083332.GA29577@infradead.org>
Date:	Fri, 12 Sep 2008 04:33:32 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Janne Grunau <j@...nau.net>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Jarod Wilson <jwilson@...hat.com>,
	linux-kernel@...r.kernel.org, Jarod Wilson <jarod@...hat.com>,
	Christoph Bartelmus <lirc@...telmus.de>,
	Mario Limonciello <superm1@...ntu.com>
Subject: Re: [PATCH 01/18] lirc core device driver infrastructure

On Fri, Sep 12, 2008 at 02:16:30AM +0200, Janne Grunau wrote:
> I'm pretty sure LIRC will be recognized by its current users, it is 
> probably enough if it is in the help text though.

But we don't care just for your current users :)  Kernel features /
drivers do need good descriptions.

> > > +		} else {
> > > +			/* if device not opened so we can sleep half a second */
> > > +			set_current_state(TASK_INTERRUPTIBLE);
> > > +			schedule_timeout(HZ/2);
> > > +		}
> >
> > Yikes.  This should use some form of more fine-grained wakeus.
> 
> added a waitqueue and wait_event

I don't think you'll need a wait queue - you can just call
wake_up_process on ir->task while the thread just sleeps in schedule().

> > > +int lirc_unregister_plugin(int minor)
> >
> > Why doesn't this one take a struct lirc_plugin pointer?
> 
> I don't know, It doesn't really help though since the struct lirc_plugin 
> is copied by value to irctl.p in lirc_register_plugin.

Well, the lifetime rules for these structures seems a litte odd.  I
would except this to work like:

struct lirc_plugin statically allocated by the driver, then passed into
lirc_register_plugin, which dynamically allocates an irdev.  The irdev
would point to the plugin, not copy it.

And btw, any chance for an s/plugin/driver/g - that's the terminology
we use everywhere else in the kernel.

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