From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753017AbcBKDpK (ORCPT ); Wed, 10 Feb 2016 22:45:10 -0500 Received: from eastrmfepo102.cox.net ([68.230.241.214]:36345 "EHLO eastrmfepo102.cox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750812AbcBKDpI (ORCPT ); Wed, 10 Feb 2016 22:45:08 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020204.56BC03C2.00A6,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=KuOTLxqN c=1 sm=1 a=o8MzhWZKAVwkrls/iQsG+Q==:17 a=iox4zFpeAAAA:8 a=FP58Ms26AAAA:8 a=7mOBRU54AAAA:8 a=danhDmx_AAAA:8 a=vTr9H3xdAAAA:8 a=Br9LfDWDAAAA:8 a=Rcl4aWOJOG5K6j_u_AMA:9 a=pILNOxqGKmIA:10 a=o8MzhWZKAVwkrls/iQsG+Q==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Subject: Re: fs/udf and udftools To: Ken Moffat , Randy Dunlap References: <56BBABAC.8010008@ou.edu> <56BBEA40.90202@infradead.org> <20160211021906.GB32580@milliways> Cc: linux-kernel@vger.kernel.org, Robert Howard , Jan Kara From: Steve Kenton Message-ID: <56BC03C1.2010802@ou.edu> Date: Wed, 10 Feb 2016 21:45:05 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160211021906.GB32580@milliways> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/10/2016 08:19 PM, Ken Moffat wrote: > On Wed, Feb 10, 2016 at 05:56:16PM -0800, Randy Dunlap wrote: >> [add Jan Kara] >> >> On 02/10/16 13:29, Steve Kenton wrote: >>> Is anyone maintaining these or am I about to volunteer for another job? I guess I should have said "developing" rather than "maintaining" for fs/udf since it's clear that someone has been keeping it running in-tree. I started with udftools from source forge and then discovered that the kernel udf driver does not support fallocate() which I was hoping to use. Thanks for the pointer to Jan Kara. I'll see how he feels about patches from the wilderness. >> >> CUrrent MAINTAINERS file says: >> >> UDF FILESYSTEM >> M: Jan Kara >> S: Maintained >> F: Documentation/filesystems/udf.txt >> F: fs/udf/ >> >> and that Doc. file says: >> >> For the latest version and toolset see: >> http://linux-udf.sourceforge.net/ Yes, that's where I started. The last release was 1.0.0b3 in 2004. Which is what the Ubuntu 14.04LTS package reports as it's version too. >> > A bit of googling for udftools suggests that gentoo are maintaining > their build, debian have patches for gcc-4 and gcc-5 among others, > Fedora have their own patches, and Arch have some patches (which > might be the same as some of hte others, I did not look). > > Looks like the normal "possibly abandonned, but still useful to some > people" software, where distros keep it building. Yep, that's where my ~works came from. Ah, thanks for the links. I'll pull them all together and see what's there. smk > > There may also be others. > > Links - > > https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-fs/udftools/ChangeLog?view=markup > > https://launchpad.net/debian/+source/udftools/+changelog > > http://pkgs.fedoraproject.org/cgit/rpms/udftools.git/tree/ > > https://aur.archlinux.org/packages/udftools/ > >> >>> I'm having to dig into fs/udf and udftools/mkudffs as part of a project I'm working on. >>> It looks like both have been lacking in personal TLC for quite a while. The changes to >>> fs/udf seem to be tree wide VFS work but not updates to things like write support and >>> udftools seems to have been frozen for >10 years. Both ~work but I'd like to fix an >>> oops I'm getting in udftools and work on adding fallocate() support to fs/udf and then >>> feed it back to the community rather than let the changes bit rot locally. >>> >>> Where to go from here? I've been reading LKML on marc: for years, mainly to see what Linus, >>> Al and a variable group of other people say/do but I've never done more than tinker with >>> the kernel locally. I'm using git for the project mentioned above but again am not an >>> expert but willing to learn. I'm not currently subscribed so please cc me if you could. >>> >>> smk >>> >> >> >> -- >> ~Randy >