All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Simmons <jsimmons@infradead.org>
To: lustre-devel@lists.lustre.org
Subject: [lustre-devel] A new drivers/staging/lustre
Date: Tue, 12 Jun 2018 01:21:53 +0100 (BST)	[thread overview]
Message-ID: <alpine.LFD.2.21.1806120114020.15735@casper.infradead.org> (raw)
In-Reply-To: <87po12ncjv.fsf@notabene.neil.brown.name>


> >> lustre-testing:
> >>    is based on 'lustre' and has most of my current lustre-related work.
> >>    It includes assorted patches that are not specifically for lustre
> >>    (rhashtables mostly at the moment).  Patches will move from here
> >>    to 'lustre' or to mainline when they are ready.
> >>    I plan to update this branch on most days that I work on Lustre,
> >>    and expect it to rebase frequently.
> >
> > I had question about that. Some things in Lustre could in theory be merged
> > into the linux kernel proper. Can that be done still?
> 
> What things?
> 
> If it measurably benefits the kernel proper, then I suspect it might be
> worth submitting.  Things can go direct without going though staging -
> they just have to be of good quality with good justification (and
> sometimes lots of patience).

One piece of work done for Lustre was the ability to submit "units" like
K, M, G for sizes to sysfs files. This was developed before string helpers
was created and the code for Lustre is well very ugly. So I rewrote it
in the style of string helpers and it can be handly for other things as 
well such as module parameters setting. Lustre does have certain features
in it debugging system that can applied to the linux kernel debugging
system. That is more down the road. Their are few others like the crypto
wrapper for alder. I don't see why that can't be mainstream.
 
> >  
> >> I'm happy to review and, if acceptable, apply patches from other
> >> developers.  I have fairly high standards, but if I don't accept your
> >> patch I'll explain why and possible help fix it.
> >
> > Also long as you talk to me :-) I'm an easy person to work with. If I 
> > refuse a patch with do the same. I might sometimes seem irrational 
> > but I have valid reasons. Well at least in my head.
> >
> > We need to really layout the roadmap.
> 
> I have very little faith in road maps - I prefer to make steps.  Once we
> have made all the steps, we can look back and see what the map looked
> like in retrospect.

I was looking to see what you plan to work on. I wanted to avoid 
duplicating work. Some things I know of done already are listed under:

https://jira.hpdd.intel.com/browse/LU-9855
https://jira.hpdd.intel.com/browse/LU-10257
https://jira.hpdd.intel.com/browse/LU-10994

Their are a few others I have to hunt down but these are the major ones.

  parent reply	other threads:[~2018-06-12  0:21 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-07  2:29 [lustre-devel] A new drivers/staging/lustre NeilBrown
2018-06-07  5:25 ` James Simmons
2018-06-07  9:58   ` NeilBrown
2018-06-07 13:07     ` Doug Oucharek
2018-06-07 13:25       ` Patrick Farrell
2018-06-07 21:50         ` NeilBrown
2018-06-07 21:38       ` NeilBrown
2018-06-07 23:06         ` Dilger, Andreas
2018-06-07 23:27           ` Patrick Farrell
2018-06-08  5:45           ` NeilBrown
2018-06-12  0:12           ` James Simmons
2018-06-12  1:24             ` NeilBrown
2018-06-12  0:21     ` James Simmons [this message]
2018-06-12  1:16       ` NeilBrown
2018-06-07 22:46 ` Dilger, Andreas
2018-06-07 22:53   ` Doug Oucharek
2018-06-07 23:24     ` Dilger, Andreas
2018-06-08  6:00       ` NeilBrown
2018-06-08  6:07   ` NeilBrown
2018-06-12  0:13 ` James Simmons
2018-06-12  0:55   ` NeilBrown
2018-06-13 21:46     ` James Simmons
2018-06-13 22:31       ` NeilBrown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.21.1806120114020.15735@casper.infradead.org \
    --to=jsimmons@infradead.org \
    --cc=lustre-devel@lists.lustre.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.