public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Leif Lindholm" <leif@nuviainc.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>,
	devel@edk2.groups.io, Andrew Fish <afish@apple.com>,
	Bob Feng <bob.c.feng@intel.com>,
	Liming Gao <liming.gao@intel.com>,
	Michael D Kinney <michael.d.kinney@intel.com>
Subject: Re: [PATCH 0/3] BaseTools,EmbeddedPkg,Maintainers.txt: Obsolete some drivers
Date: Thu, 30 Apr 2020 14:28:43 +0100	[thread overview]
Message-ID: <20200430132843.GS21486@vanye> (raw)
In-Reply-To: <bcecd2df-27c8-38c9-0214-2804495f9c59@redhat.com>

On Thu, Apr 30, 2020 at 13:17:26 +0200, Laszlo Ersek wrote:
> On 04/29/20 23:47, Ard Biesheuvel wrote:
> > On 4/29/20 11:45 PM, Leif Lindholm wrote:
> >> On Wed, Apr 29, 2020 at 22:04:08 +0200, Ard Biesheuvel wrote:
> >>>>> I am mostly concerned about the use of MmcDxe in new platforms. The
> >>>>> other
> >>>>> bits I'm not too worried about, and I think it would be fine to
> >>>>> move those
> >>>>> into Platform/ARM/VExpressPkg in edk2-platforms, instead of hoping
> >>>>> that
> >>>>> someone will turn up and turn them into driver model drivers.
> >>>>
> >>>> We could, although I would prefer not adding code to edk2-platforms
> >>>> that would not be accepted was it submitted as a new contribution.
> >>>> The SATA controller, I would ideally re-review and merge properly.
> >>>>
> >>>> If we do include the other drivers in platform-specific directories, I
> >>>> want them to come with ... strongly worded readmes.
> >>>>
> >>>
> >>> Right.
> >>>
> >>> Should we have some format for that? A way to log shortcomings along
> >>> with
> >>> the code?
> >>
> >> Thinking a bit more on this, maybe what we should do is add a template
> >> to each file's top comment block. Draft proposal:
> >>
> >>    *
> >>    * WARNING:
> >>    * This driver fails to follow the UEFI driver model without a good
> >>    * reason, and only remains in the tree because it is still used by
> >>    * a small number of platforms. It will removed when no longer used.
> >>    * New platforms should not use it, and no one should use this as
> >>    * reference code for developing new drivers.
> >>    *
> >>
> > 
> > Works for me
> > 
> 
> You could also (or alternatively) add a separate file "DEPRECATED.txt"
> to the directory -- sometimes people don't read file-top comments,
> before duplicating or editing code. Something that's visible with a
> simple "ls -l" might stand out more.

I think what's more visible depends on the use-case.
A comment at the top of the file is at least very visible to the
reviewer if someone submits Yet Another Clone of an inadvisible
driver.

A DEPRECATED.txt might be a good ide for something like the
EmbeddedPkg MmcDxe which we wan't people to stop *using* as opposed to
copying.

Ard?

Thanks!

/
    Leif


> 
> Just a thought, I'm neutral on this.
> 
> Thanks
> Laszlo
> 

  reply	other threads:[~2020-04-30 13:28 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-29 16:36 [PATCH 0/3] BaseTools,EmbeddedPkg,Maintainers.txt: Obsolete some drivers Leif Lindholm
2020-04-29 16:36 ` [PATCH 1/3] BaseTools: add handling for 'S:' flag to GetMaintainer.py Leif Lindholm
2020-04-30  7:00   ` Bob Feng
2020-04-29 16:36 ` [PATCH 2/3] Maintainers.txt: mark EmbeddedPkg MmcDxe as Obsolete Leif Lindholm
2020-04-29 20:12   ` [edk2-devel] " Laszlo Ersek
2020-04-29 16:36 ` [PATCH 3/3] Maintainers.txt: mark EmbeddedPkg hw drivers as bsolete Leif Lindholm
2020-04-29 20:14   ` [edk2-devel] " Laszlo Ersek
2020-04-29 17:51 ` [PATCH 0/3] BaseTools,EmbeddedPkg,Maintainers.txt: Obsolete some drivers Ard Biesheuvel
2020-04-29 19:53   ` Leif Lindholm
2020-04-29 20:04     ` Ard Biesheuvel
2020-04-29 21:45       ` Leif Lindholm
2020-04-29 21:47         ` Ard Biesheuvel
2020-04-30 11:17           ` Laszlo Ersek
2020-04-30 13:28             ` Leif Lindholm [this message]
2020-04-30 13:43               ` Ard Biesheuvel
2020-04-30 14:59                 ` Leif Lindholm
2020-04-29 20:14 ` [edk2-devel] " Andrei Warkentin

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-list 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=20200430132843.GS21486@vanye \
    --to=devel@edk2.groups.io \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox