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

[Dilger, Andreas]

On 2013/09/11 10:29 AM, "Christoph Hellwig" <hch@xxxxxxxxxxxxx> wrote:
>Talking about nasty code, the whole linux-curproc.c is highly
>questionable:
>
> - cfs_curproc_groups_nr:
>   	unused and should be removed

This is already removed in the upstream Lustre code, it just hasn't made
it into the kernel yet.

>- cfs_cap_raise/cfs_cap_lower/cfs_cap_raised:
>   	needs to go away, modyules must not change access permissions
>	on behalf of processes

These are only used on the server so that threads running as user UID/GID
can write to recovery log files.  There is likely a different way that
this could be done, it has probably been this way from years ago when we
used the VFS to do file IO on the server and it was doing file permission
checking again.

> - the whole cfs_cap_t handling also needs to go away, passing around
>   capabilities is not a concept the kernel supports for a reason
>
> - current_is_32bit:
>	Code should just use is_compat_task directly.

This was already removed in the upstream Lustre code.

>I've just taken the time to walk through this one file, but it seems
>like most of libcfs is just as bad.

Sure, and that's why Lustre is in drivers/staging and not fs/, and I don't
make any claims to the contrary.  We are slowly cleaning out these macros
(added when we wanted to get Lustre working on MacOS and WinNT), but it
will take some time.  XFS lived with an IRIX shim layer for years, and
still
has a whole vnode abstraction layer that nobody seems to be complaining
about, so I don't think it is unreasonable for us to take some time to
clean
up Lustre.

Cheers, Andreas
-- 
Andreas Dilger

Lustre Software Architect
Intel High Performance Data Division


--
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/