FUJITA Tomonori wrote: > On Tue, 24 Mar 2009 10:41:32 +0200 > Boaz Harrosh <bharrosh@xxxxxxxxxxx> wrote: > >> Boaz Harrosh wrote: >>> Hi Tomo Jens >>> >>> Tomo you never ack-by on this patch. I absolutely needs this for the >>> user-mode API of osd-initiator. Which is needed with up-coming exofs >>> utilities. >>> >>> What do you want to do? >>> >>> Thanks >>> >> Hi Jens. >> >> I absolutely need this patch for 2.6.30 merge window. It is totally >> un-dangerous since defaults are left unchanged. > > The question is we really need this feature or not. Though I guess > that we need to address this starvation issue. > Good, this patch solves exactly that problem. Thanks Tomo > >> I need it because the user-mode utilities for osd and exofs that >> correspond to code in 2.6.30 will need this patch to compile, >> because they use a flag constant defined in this patch. > > What do the user-mode utilities does for what? > The immediate problem is that the code uses this API and will not compile without it. This is because the user-mode library exports the exact API and fixture set as the Kernel one. Submitting commands in order is one important aspect. This is a general purpose library for developers to use, with published API. In the purpose of attracting users to develop for OSD, so the argument of not yet used does not apply. I don't want the users to go around inventing work arounds when the solution is obvious and the blame is clear. > You always say something like, "we need this for OSD, pNFS or > something". But I'm not sure you explain the detailed background. > I don't think this argument applies to this particular patch. The shortcoming of bsg code is clear and should be fixed. And it has a user. libosd in user-mode. But if you want details then just calling osd_execute_request_async() from user-mode in succession, will reveal this problem. Not fixing it now will hide mines to any developer that wants to use libosd. > A typical example is, why does the osd library export lots of > functions that exofs doesn't use with EXPORT_SYMBOL This is unrelated to this patch of course, but... They are all used by the osd_ktest.ko which you objected to be included in the Kernel, and I removed. > instead of > EXPORT_SYMBOL_GPL? What is that got to do with it? The libosd.ko is a general purpose library for any kind of user. It exports the API defined in osd_initiator.h. This API is globally public, and has until now 3 implementations Linux-kernel, Linux-user-mode, BSD-kernel. I hope it will have many more implementations on all major OSs. I do not designate this API to be private Linux API, hence EXPORT_SYMBOL_GPL does not apply. Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
