Re: [PATCH] staging: Disable lustre file system for MIPS, SH, and XTENSA

[Peng Tao]

On Wed, Sep 11, 2013 at 10:30 AM, Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
> On Wed, Sep 11, 2013 at 10:25:57AM +0800, Peng Tao wrote:
>> On Wed, Sep 11, 2013 at 9:44 AM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
>> > On Wed, Sep 11, 2013 at 01:14:11AM +0800, Peng Tao wrote:
>> >> The problem is access_process_vm() is not exported since certain
>> >> version of kernel including the latest. According to Christoph in the
>> >> other mail, access_process_vm() is also a core mm function that is not
>> >> supposed to be exported. Then what kind of change shall we make in
>> >> order to keep current functionality?
>> >
>> > You should remove the higher level functionality, kernel modules are
>> > not supposed to look at userspace environment variables.
>> >
>> OK. I've looked at the specific case that Lustre uses
>> access_process_vm() to get the jobid environment variable and package
>> it into the RPC requests to server. However, it turns out that in the
>> latest Lustre server code, the jobid in a request is not used
>> anywhere. So it looks like we can just get rid of it.
>>
>> Andreas, could you please confirm this? Is the jobid an obsolete
>> parameter that can be abandoned? Or is there plan to use it somehow in
>> the future?
>>
> "Plan to use it in the future" is not a reason or argument to keep it today,
> especially if it is something you are not supposed to do to start with.
> If you ever need it, you should be able to find some other means to
> support a similar functionality.
>
I'm not fighting against removing the piece of code. But if there is a
strong reason to keep the functionality, we need to find a way to
implement it. The convenience of using environment variables is that
job scheduler can set the environment and other existing applications
don't have to change. Are there other means to do the same? ioctl and
upcall both need application change AFAIK.

Again, if the code is just obsolete, which is quite likely but needs
Andreas' confirmation, we can just remove it.

Thanks,
Tao
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/