linux-kernel - Re: [PATCH] Topcliff PHUB: Generate PacketHub driver

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201006151237.30698.arnd@arndb.de>
Date:	Tue, 15 Jun 2010 12:37:30 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	"Masayuki Ohtake" <masa-korg@....okisemi.com>
Cc:	"Wang, Yong Y" <yong.y.wang@...el.com>,
	"Wang, Qi" <qi.wang@...el.com>, "Intel OTC" <joel.clark@...el.com>,
	"Andrew" <andrew.chih.howe.khor@...el.com>,
	"LKML" <linux-kernel@...r.kernel.org>,
	"Alan Cox" <alan@...rguk.ukuu.org.uk>
Subject: Re: [PATCH] Topcliff PHUB: Generate PacketHub driver

On Tuesday 15 June 2010, Masayuki Ohtake wrote:
> I have additional question.
> > - When the user does an llseek or pread, the *pos argument is not zero,
> >   so you should return data from the middle, but you still return data
> >   from the beginning.
> 
> 
> Must a driver read/write method support '*pos' parameter ?
> We think PHUB doesn't have to support '*pos',
> and ,we think, PHUB OROM R/W function supports only whole of ROM data R/W is enough.
> Please give us your opinion.

While you do not strictly need to support *pos to get the functionality
you want, it should be easy enough to implement and it will make the
read/write callbacks conform to the general semantics of file based
I/O. Especially if you want to be able to use tools like 'cat', 'hexdump'
or 'dd' on the file descriptor, you need to implement support for
short reads. If you are unsure about how to do that correctly, I can
help you some more. A good reference implementation is
simple_transaction_read in fs/libfs.c, which simply returns some
private memory.

If there is a strict hardware limitation that prevents you from doing
partial writes, you could expose that in the interface and return -EIO
in case of invalid *pos or size arguements, but my impression was that
the hardware can deal with bytewise access.

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