public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: Markus Lidel <Markus.Lidel@shadowconnect.com>
Cc: Christoph Hellwig <hch@lst.de>, linux-kernel@vger.kernel.org
Subject: Re: sysfs abuse in recent i2o changes
Date: Thu, 7 Jul 2005 23:00:28 -0700	[thread overview]
Message-ID: <20050708060028.GB5323@suse.de> (raw)
In-Reply-To: <42C25CBF.8000509@shadowconnect.com>

On Wed, Jun 29, 2005 at 10:33:03AM +0200, Markus Lidel wrote:
> Hello,
> 
> Greg KH wrote:
> >On Tue, Jun 28, 2005 at 08:08:20PM +0200, Markus Lidel wrote:
> >>Greg KH wrote:
> >>>On Tue, Jun 28, 2005 at 05:02:41PM +0200, Markus Lidel wrote:
> >>>>I know, but i hopefully also have a good reason to do so... First, the 
> >>>>attributes provided through these functions are for accessing the 
> >>>>firmware... The controller has a little limitation, it could only 
> >>>>handle 64 blocks, but sysfs only have 4k...
> >>>>Now there are two options:
> >>>>1) when writing: read a 64k block, merge it with the 4k block and write 
> >>>>it back, when reading: read a 64k block and only return the needed 4k 
> >>>>block.
> >>>>2) extend the sysfs attribute to allow 64k blocks
> >>>>IMHO the first is not a very good solution, because for a 64k block it 
> >>>>has to be written 16 times...
> >>>>Of course if someone finds a better solution i would be glad to hear 
> >>>>about it...
> >>>Use the binary file interface of sysfs, which was written exactly for
> >>>this kind of thing. :)
> >>Oh i tried to use the binary interface, but i haven't found a way to 
> >>increase the block size beyond 4k, could you please tell me how i could 
> >>adjust it, or where i could read about it?
> >Your code should not care about the block size of the data given to you,
> >as userspace could be giving you 1 byte at a time.  Buffer it up
> 
> The driver don't care about the block size but the device do... Of course 
> you could send 1 byte at a time, but if you do so the controller blows up...

Then you need to prevent this in the kernel.

> >yourself and then write it out to the device when needed.
> 
> Yep, but this way there is much more code needed to handle it, and also 
> the memory for the buffer may be used longer then just for the read/write...

No, use the firmware interface, that's what it is there for.

> >But if you are doing this for firmware, then please use the kernel
> >firmware interface, it does all of the buffering for you.
> 
> In my case the interface is for updating the firmware and also to access 
> the configuration settings of the controller... The way to retrieve/store 
> the firmware and the configuration settings is the same, so i still have 
> to implement the sysfs attributes for the configuration settings...

Ok, then use the binary file, and then buffer it up properly yourself,
like the firmware interface does.

> >Either way, having your own file_ops in sysfs is not allowed.
> 
> That was the reason i not changed sysfs and only used it in my own 
> module, because i see that it is only needed because of the limitations 
> of the hardware...

No, please don't do this, either use the binary file interface, or the
firmware one.  Don't use your own file_ops.

thanks,

greg k-h

  reply	other threads:[~2005-07-08  6:00 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-28 11:21 sysfs abuse in recent i2o changes Christoph Hellwig
2005-06-28 15:02 ` Markus Lidel
2005-06-28 16:21   ` Greg KH
2005-06-28 18:08     ` Markus Lidel
2005-06-28 18:07       ` Greg KH
2005-06-29  8:33         ` Markus Lidel
2005-07-08  6:00           ` Greg KH [this message]
2005-07-08 11:11             ` Markus Lidel
2005-07-31 14:09             ` Christoph Hellwig
2005-07-31 15:40               ` Markus Lidel
2005-07-31 21:19                 ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050708060028.GB5323@suse.de \
    --to=gregkh@suse.de \
    --cc=Markus.Lidel@shadowconnect.com \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox