| 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
| ||
|
Message-ID: <4B8F72B5.3000408@ladisch.de> Date: Thu, 04 Mar 2010 09:43:33 +0100 From: Clemens Ladisch <clemens@...isch.de> To: Magnus Lynch <maglyx@...il.com> CC: venkatesh.pallipadi@...el.com, vojtech@...e.cz, linux-kernel@...r.kernel.org Subject: Re: [PATCH] hpet: factor timer allocate from open Magnus Lynch wrote: > On Mon, Mar 1, 2010 at 1:59 AM, Clemens Ladisch <clemens@...isch.de> wrote: > > Applications might want to use HPET_INFO to find out which timer they > > got, so I think the driver cannot avoid allocating a timer in this case. > > Oh, I missed commenting this in my first reply. I chose to make > HPET_INFO specify timer -1 in case a timer isn't currently allocated. > You think there are extant cases of programs depending on open then > immediate HPET_INFO having a timer allocated? Seems obscure to me. Get information about the just allocated timer seems to be the main purpose of this ioctl to me. None of the fields in struct hpet_info looks to be interesting to an application that only wants to read the main timer through mmap(). > If so I can change that. I did add the explicit form of allocating > timers to accomodate such a case hypothetically (open, allocate timer, > get info). This wouldn't be backwards compatible. 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/
Powered by blists - more mailing lists