Messages in this thread | | | From | "Masayuki Ohtake" <> | Subject | Re: [PATCH] Topcliff PHUB: Generate PacketHub driver | Date | Tue, 15 Jun 2010 21:14:00 +0900 |
| |
Hi Arnd,
Thank you for your comments. I will study your showed reference.
Thanks, Ohtake
----- Original Message ----- From: "Arnd Bergmann" <arnd@arndb.de> To: "Masayuki Ohtake" <masa-korg@dsn.okisemi.com> Cc: "Wang, Yong Y" <yong.y.wang@intel.com>; "Wang, Qi" <qi.wang@intel.com>; "Intel OTC" <joel.clark@intel.com>; "Andrew" <andrew.chih.howe.khor@intel.com>; "LKML" <linux-kernel@vger.kernel.org>; "Alan Cox" <alan@lxorguk.ukuu.org.uk> Sent: Tuesday, June 15, 2010 7:37 PM 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 >
| |