Re: [PATCH 0/2] File-backed Storage Gadget converted to use composite framework

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

 



On Fri, 14 Aug 2009, Michal Nazarewicz wrote:
The patchset introduces a File-backed Storage Gadget (FSG) converted
to use a composite framework.  The first patch adds File-backed
Storage Function (FSF) which is heavily based on the FSG.  The second
patch converts FSG to use FSF and composite framework.

On Fri, 14 Aug 2009 17:21:16 +0200, Alan Stern wrote:
I'm glad that someone has decided to do this work!

;)

Moreover, FSF introduces several changes compared to FSG.  First of
all, the read-only flag, removable and CD-ROM emulation is configured
per-LUN basis rather then globally for the whole function.

On the contrary: FSG has always made the read-only flag per-LUN.

True, my mistake.

There didn't seem to be any need to make the other two flags per-LUN,
on the theory that all the LUNs in a device should have the same
characteristics.

Well, there's this comment in the FSG:

  68 * ...............................................................  Ideally
  69 * each LUN would be settable independently as a disk drive or a CD-ROM
  70 * drive, but currently all LUNs have to be the same type.  ..........

which I acted upon.  Anyways, I guess having those configurable per-LUN
is not a bad, is it?

Regardless, this seems unrelated to the matter of converting things
over to the composite framework.  Perhaps you should separate it out
into a completely independent patch.

Yes, I agree, however, while working on the function all my previous
versions either didn't compile or didn't work, so in the end, the only
patch that is worth showing (ie. compiles, seems to work and code is
not very unclean) is the one I've posted.

Now, what's yet to be done is move the kernel thread related data
to the fsf_common structure.  Currently, when FSF is added to two
configurations two kernel threads are created -- only one is active at
a time but still, it's not good design.

So if you added two FSF interfaces to each of two configurations, there
would be four threads?  Yes, that should be fixed.

Granted.  I haven't touched that yet (in fact I tried but then postponed
seeing it's not that trivial) as I'm not sure if I fully understand the way
threads in FSG (and now FSF) work (and that's also why comments are
welcome :) )so didn't want to break something prior to posting.  I guess
after validating the part I've posted there will be time for further
improvements.

Anyways, thanks for the reply!

--
Best regards,                                            _     _
 .o. | Liege of Serenly Enlightened Majesty of         o' \,=./ `o
 ..o | Computer Science,  Michał "mina86" Nazarewicz      (o o)
 ooo +-<m.nazarewicz@xxxxxxxxxxx>-<mina86@xxxxxxxxxx>-ooO--(_)--Ooo--
--
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