public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Markus Lidel <Markus.Lidel@shadowconnect.com>
To: Greg KH <gregkh@suse.de>
Cc: Christoph Hellwig <hch@lst.de>, linux-kernel@vger.kernel.org
Subject: Re: sysfs abuse in recent i2o changes
Date: Wed, 29 Jun 2005 10:33:03 +0200	[thread overview]
Message-ID: <42C25CBF.8000509@shadowconnect.com> (raw)
In-Reply-To: <20050628180719.GA11585@suse.de>

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...

> 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...

> 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...

> 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...

Thank you very much.


Best regards,


Markus Lidel
------------------------------------------
Markus Lidel (Senior IT Consultant)

Shadow Connect GmbH
Carl-Reisch-Weg 12
D-86381 Krumbach
Germany

Phone:  +49 82 82/99 51-0
Fax:    +49 82 82/99 51-11

E-Mail: Markus.Lidel@shadowconnect.com
URL:    http://www.shadowconnect.com

  reply	other threads:[~2005-06-29  8:25 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 [this message]
2005-07-08  6:00           ` Greg KH
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=42C25CBF.8000509@shadowconnect.com \
    --to=markus.lidel@shadowconnect.com \
    --cc=gregkh@suse.de \
    --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