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
>
next prev parent 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