MMC ioctl or sysfs interface?

MMC ioctl or sysfs interface?

[Pierre Ossman]

MMC cards have the feature to lock down cards using a special password.
When the cards is locked it will not accept any commands except
lock-related ones.

I've been thinking about implementing support for this in Linux but I'm
not sure which interface should be used for it. The functions needed are:

* Lock card with a supplied password.
* Unlock card using a password.
* Clear password.
* Erase lock (clears the card and removes the lock).

Since you want some feedback with the result of the operation an ioctl
seemed appropriate. But mmc cards don't have device nodes so there is
nothing to do ioctls on. So in that perspective a sysfs solution would
be better. But how to you do the interaction with userspace in a good way?

Ideas are very welcome.

Rgds
Pierre

Re: MMC ioctl or sysfs interface?

[Chris Wedgwood]

On Thu, Jun 09, 2005 at 03:08:41PM +0200, Pierre Ossman wrote:

> MMC cards have the feature to lock down cards using a special
> password.  When the cards is locked it will not accept any commands
> except lock-related ones.

IDE disks can do this too --- is it the same interface?

Re: MMC ioctl or sysfs interface?

[Pierre Ossman]

Chris Wedgwood wrote:

>On Thu, Jun 09, 2005 at 03:08:41PM +0200, Pierre Ossman wrote:
>
>  
>
>>MMC cards have the feature to lock down cards using a special
>>password.  When the cards is locked it will not accept any commands
>>except lock-related ones.
>>    
>>
>
>IDE disks can do this too --- is it the same interface?
>  
>

No. ATA and MMC are very different protocols.

Re: MMC ioctl or sysfs interface?

[Alan Cox]

On Gwe, 2005-06-10 at 22:00, Pierre Ossman wrote:
> >IDE disks can do this too --- is it the same interface?
> No. ATA and MMC are very different protocols.

It would be good to have the same ioctls on both block devices or sysfs
files however.

Re: MMC ioctl or sysfs interface?

[Pierre Ossman]

Alan Cox wrote:

>On Gwe, 2005-06-10 at 22:00, Pierre Ossman wrote:
>  
>
>>>IDE disks can do this too --- is it the same interface?
>>>      
>>>
>>No. ATA and MMC are very different protocols.
>>    
>>
>
>It would be good to have the same ioctls on both block devices or sysfs
>files however.
>  
>

I wasn't aware that you could do ioctl on sysfs nodes. I guess I'll have
to dig a bit deeper in the documentation/code.

As for keeping the same ioctl. If the current ioctls are similar enough
then I don't see why not. The userspace tools might need changing though
since all ATA ioctls won't be available. What tool is used for locking
an ATA drive? And is there some documentation detailing the lock
commands and related ioctls so I can compare with what I'm trying to do?

Rgds
Pierre

Re: MMC ioctl or sysfs interface?

[Alan Cox]

On Sul, 2005-06-12 at 19:15, Pierre Ossman wrote:
> Alan Cox wrote:
> I wasn't aware that you could do ioctl on sysfs nodes. I guess I'll have
> to dig a bit deeper in the documentation/code.

You can add support, but you'll need a device node one day anyway so you
might as well give up on the sysfs only game - it doesn't IMHO work.

> As for keeping the same ioctl. If the current ioctls are similar enough
> then I don't see why not. The userspace tools might need changing though
> since all ATA ioctls won't be available. What tool is used for locking
> an ATA drive? And is there some documentation detailing the lock
> commands and related ioctls so I can compare with what I'm trying to do?

Right now for ATA you issue a taskfile ioctl, for SCSI you use SG_IO and
applications are not presented with any uniformity.

Re: MMC ioctl or sysfs interface?

[Jon Smirl]

On 6/12/05, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Sul, 2005-06-12 at 19:15, Pierre Ossman wrote:
> > Alan Cox wrote:
> > I wasn't aware that you could do ioctl on sysfs nodes. I guess I'll have
> > to dig a bit deeper in the documentation/code.
> 
> You can add support, but you'll need a device node one day anyway so you
> might as well give up on the sysfs only game - it doesn't IMHO work.

I have a sysfs interface for fbdev in the kernel -
/sys/class/graphics/fb0/*  It is working well for me and it's the only
interface EGL uses to access fbdev. It's all controllable with strings
that can be scripted if you want. If you play with it some of the
attributes are broken, there are fixes for them in the pipeline.

I also have DRM loaded for the same hardware. I'd have to think about
it for a while to see if DRM could go sysfs only. I'm using DRM to map
the framebuffer instead of fbdev.

One big difference is that a device node can carry session state. If
you open the device the file handle can track things belonging to the
session. With sysfs sessions are more of a mess. fbdev works cleanly
because there is no session state.

-- 
Jon Smirl
jonsmirl@gmail.com