Re: [PATCH 2] introduce-mass-storage-arbitration.patch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/24/09 21:52, Somebody in the thread at some point said:

Hi -

Yes.  That's different from what you were talking about before.

Actually it really was what I was talking about before, sorry if it was unclear.

Several people have requested notifications from the kernel as to when
a gadget's USB cable is plugged in or unplugged.  This is completely
separate from g-file-storage; it should be handled at the level of the
device controller driver.  After all, people using other kinds of
gadget drivers will want to receive these notifications too.  And it's
still true that you don't need arbitration when the cable is plugged in
or unplugged.

Right that's a useful thing generally and it's clear that belongs in the next level down.

(The question of which gadget driver is loaded -- g_file_storage vs.
g_ether -- can already be answered using the information available in
sysfs.)

You can include this in the netlink environment if you generate a netlink action as well, fwiw.

Netlink is pretty nice, one of the things it eliminates is having hardcoded sys paths in userspace, since the correct sys context for the device (or lun) creating the event is present in the environment of the Netlink message. That also makes it magically work for multiple LUN / partition case without statically knowing the different sysfs paths or even how many there are beforehand.

We are already having a thread service kernel uvent netlink stuff to get power_supply class traffic, that also works great.

That's step 4.  As for step 8, I agreed earlier that it might be nice
to have some sort of notification scheme for when the host ejects the
medium.  Isn't sysfs_notify() good enough?  You don't need any sort of
arbitration for ejects.

Right there's nothing to confirm after an eject the device can definitely have the storage right away.

Do the comments above help?

Yeah. I think your idea about basically "doing the arbitration" by defaulting to no backing storage and then adding it when all is done on the device side is superior to what I'm doing. (I just didn't know that adding the storage by the sysfs will prompt the host to automount it.)

However, my patch is working good now on my side. What I will do is stick with my patch in my tree until these other solutions get implemented elsewhere.

Thanks a lot for your time talking it through and Happy Christmas :-)

-Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux