linux-kernel - Re: [RFC][PATCH] HPET: register additional counter-only char device

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: <1207922810.26014.33.camel@laphroaig>
Date:	Fri, 11 Apr 2008 16:06:50 +0200
From:	Dimitri Gorokhovik <dimitri.gorokhovik@...com.fr>
To:	Clemens Ladisch <clemens@...isch.de>
Cc:	tglx@...utronix.de, linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCH] HPET: register additional counter-only char device

On Fri, 2008-04-11 at 15:20 +0200, Clemens Ladisch wrote:
> Dimitri Gorokhovik wrote:
> > I need to have many processes all reading from userspace the counter register
> > of the (same) HPET hardware. Just reading counter values, not handling timers,
> > enabling/disabling interrupts etc. `/dev/hpet' doesn't allow for this, as the
> > number of times it can be opened is limited by the number of timers available.
> 
> Indeed.  The driver assumes that userspace wants to program its own
> timer (like an RTC device).  Allowing mmap() on the hardware counter was
> more an afterthought.
> 
> > What would be the right way to implement such a support? For now, I simply
> > register a new misc device, '/dev/hpetctr', along with '/dev/hpet', for the same
> > ACPI device and on the same occasion.
> 
> Your patch circumvents CONFIG_HPET_MMAP.

Right. I hesitated to put it in, but multiple #ifdef/endif clutter too
much the resulting code. Something better should be devised in this
case, like separating the added code into another file, changing a
couple of symbols from static to extern etc.

However, why people wanted the original 'mmap' of /dev/hpet to be
disabled? Probably to prevent the HPET registers from poking with? Gain
in code size is too small, can't think it was the primary reason. If so,
isn't having a read-only mapping enough in itself?


> Another possibility would be to allow the device to be opened
> infinitely many times but not to allocate a hardware timer until one of
> the ioctls is called.  This means that opening /dev/hpet does not
> guarantee that a timer is available, but this has already been possible
> previously because request_irq() might fail.

Good point. The patch would be much more intrusive and voluminous (and
coming from a total newcomer). Would there be an interest for such a
patch? If yes, I might find some time to spend on it.

I did try to figure out the cleanest way by myself before posting, and I
couldn't mix and match several points about HPET:

-- /dev/hpet can only be opened with O_RDONLY, but for fiddling with
interrupts IMO write perms suit much better. One could imagine opening
lots of instances under O_RDONLY. Obviously, this way is doomed now
because of legacy apps.

-- to me, /dev/hpet is primarily a timer, not just a counter. It seems
wrong to me if it, once opened, would mostly fail to its primary
function (but this of course is all subjective matter).


Thanks for your comments!



 
> 
> 
> Regards,
> Clemens
--
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/