Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752942Ab0FOMOH (ORCPT ); Tue, 15 Jun 2010 08:14:07 -0400 Received: from sm-d311v.smileserver.ne.jp ([203.211.202.206]:39334 "EHLO sm-d311v.smileserver.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751633Ab0FOMOF (ORCPT ); Tue, 15 Jun 2010 08:14:05 -0400 Message-ID: <000f01cb0c84$3e522ba0$66f8800a@maildom.okisemi.com> From: "Masayuki Ohtake" To: "Arnd Bergmann" Cc: "Wang, Yong Y" , "Wang, Qi" , "Intel OTC" , "Andrew" , "LKML" , "Alan Cox" References: <001401cb0c58$33b3ae20$66f8800a@maildom.okisemi.com> <201006151237.30698.arnd@arndb.de> Subject: Re: [PATCH] Topcliff PHUB: Generate PacketHub driver Date: Tue, 15 Jun 2010 21:14:00 +0900 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1983 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1983 X-Hosting-Pf: 0 X-NAI-Spam-Score: 1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2150 Lines: 53 Hi Arnd, Thank you for your comments. I will study your showed reference. Thanks, Ohtake ----- Original Message ----- From: "Arnd Bergmann" To: "Masayuki Ohtake" Cc: "Wang, Yong Y" ; "Wang, Qi" ; "Intel OTC" ; "Andrew" ; "LKML" ; "Alan Cox" 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/