The "part 1", "part 2" commit messages are a result of me building the linux-next tree directly from a patch series I posted to fs-devel. I didn't know how much commit history you might want to see, but we've been focusing on trying to go upstream for several years and my github tree has several years of commit history representing numerous branches across rebases: https://github.com/hubcapsc/linux The double sign-off's are also a side-effect of my inelegant use of of git-am while I built the linux-next tree from the patch series I had posted (and already signed off on)... If the code doesn't look obviously horrible, it's because a lot of good people have worked on the kernel module in the past, it has been in use since 2.4. When I started working with the kernel module a couple of years ago it didn't work past 2.6, so I've done a lot of "code janitor" type work and fixups, a lot of work with the CodingStyle document. Christoph Hellwig helped immensely with improvements that were beyond my depth of knowledge. We can commit to working on "a" and "b" in your message, either before or after going upstream, whichever you specify. As one result of Greg KH's review, I replaced all the "proc" code with "sysfs" and "debugfs" code... we are eager to be responsive to reviews. If some reviewers are off-put at the idea of having to build the userspace part of Orangefs, there is a cheat-sheet for that in orangefs.txt. Walt Ligon has been with pvfs (now orangefs) since the beginning, and is still the lead architect/programmer of the userspace filesystem. A major new revision is in the works, and I've put a lot of work into making sure the kernel module will work across revisions. Omnibond is committed to maintaining the kernel module, we won't just throw it over the wall and walk away. -Mike "not Mark <g>" On Wed, Sep 2, 2015 at 7:34 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > [ I haven't gotten to the filesystem pulls yet, and by now won't until > tomorrow, but I'm looking a bit ahead here.. ] > > On Tue, Sep 1, 2015 at 8:42 AM, Mike Marshall <hubcap@xxxxxxxxxxxx> wrote: >> >> Please consider pulling Orangefs from >> >> git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux.git for-next > > I'd love to have comments and ack's from people. From the Cc I'd hope > we have people who have followed this, but there's no indication of > acks etc in the commits, so.. > > A few quick comments from just skimming the code and the commits: > > - the commit messages aren't really helpful. "Orangefs: kernel client > part 4". Yeah, that doesn't really say anything > > - the sign-offs are odd (omnibond _and_ clemson.edu?) > > - the code doesn't look obviously horrible, but I did notice that > > (a) the iovecs are walked manually (eg > pvfs_bufmap_copy_to_user_iovec()). I would really want to see the code > use the iov_iter infrastructure > > (b) iovec_iter may be new, but the wait_event() helpers are not, > and the code (eg pvfs2_devreq_writev) is using the really > old-fashioned way to wait for things (with add_wait_queue, > set_current_state, etc etc). I'd *really* want to see the much > simpler-to-read (and less bug-prone) wait_event() models used. > > - naming is an odd mix of "orangefs" and "pvfs2", both in the code > and in the filenames. > > It would be lovely to get some comments from other people. Al? Anybody > who has been involved with this? > > I'd also like to have more of an idea of who expects to maintain this? > I'm assuming that's Mark (and omnibond?), but it would be good to hear > who the users are and what the long-term support is supposed to be. We > have had a tradition of filesystems that don't then get used very > much, and they bit-rot. > > Linus -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
