From: "Qiu, Michael" <michael.qiu@intel.com>
To: Stephen Hurd <stephen.hurd@broadcom.com>,
Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, Carl Tung <carl.tung@broadcom.com>,
David Christensen <david.christensen@broadcom.com>
Subject: Re: [dpdk-dev] New driver (large patch) question.
Date: Thu, 3 Mar 2016 05:53:52 +0000 [thread overview]
Message-ID: <533710CFB86FA344BFBF2D6802E6028622F5BCE5@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <CAJ9nmBaLEJvcDPiFcQOUxDwcwgFu4E144eM=Hi6jrxo8S-giJw@mail.gmail.com>
On 3/3/2016 7:11 AM, Stephen Hurd wrote:
> On Wed, Mar 2, 2016 at 2:15 PM, Thomas Monjalon <thomas.monjalon@6wind.com>
> wrote:
>
>>> The comments in it are the only publicly available
>>> documentation on the hardware I'm aware of.
>> So you must keep the comments.
>>
> That's my goal, but the comments are well over the 300k limit.
>
>
>>> The driver itself doesn't have a lot of optional features in it, it's the
>>> header file that's too big.
>> It is big because there are many different things.
>> You can split the file in different patches.
>> Examples:
>> - a patch for RSS will bring the hardware structures for RSS
>> - a patch for the stats will bring the hardware stats structures
>> etc
>>
> Should I split additional definitions/documentation that's not currently
> used in the driver as well? Or should it stay as only enough to document
> what the driver already does?
>
> The header file is expected to be publicly released in the future, so I
> tried to keep it as close to the original as possible. I'm not strongly
> attached to this approach, but it does make it easier to support future
> firmware releases.
>
> It's a fairly work-intensive project to deconstruct the existing driver
> into a series of small patches that work at each step, is this a hard
> requirement? (if so, I'd better get cracking)
Does original header file has it's own commit log(like it in other
project)? If yes, it could make your life simpler.
Thanks,
Michael
> PS: please answer inline
> Sorry, $work just switched us to GMail and I'm still learning the ropes.
>
next prev parent reply other threads:[~2016-03-03 5:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAJ9nmBaWh8WsuzQcAfrebjaFNYSGsGxEd5Y5DQfWTPuxYY8XWQ@mail.gmail.com>
2016-03-02 10:21 ` Thomas Monjalon
2016-03-02 16:24 ` Stephen Hemminger
2016-03-02 21:30 ` Stephen Hurd
2016-03-02 21:54 ` Thomas Monjalon
2016-03-02 22:06 ` Stephen Hurd
2016-03-02 22:12 ` Wiles, Keith
2016-03-02 22:15 ` Thomas Monjalon
2016-03-02 23:10 ` Stephen Hurd
2016-03-03 0:29 ` Thomas Monjalon
2016-03-03 1:04 ` Stephen Hurd
2016-03-03 5:53 ` Qiu, Michael [this message]
2016-03-03 19:40 ` Stephen Hurd
2016-03-02 23:07 ` Vincent JARDIN
2016-03-02 23:43 ` Bruce Richardson
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=533710CFB86FA344BFBF2D6802E6028622F5BCE5@SHSMSX101.ccr.corp.intel.com \
--to=michael.qiu@intel.com \
--cc=carl.tung@broadcom.com \
--cc=david.christensen@broadcom.com \
--cc=dev@dpdk.org \
--cc=stephen.hurd@broadcom.com \
--cc=thomas.monjalon@6wind.com \
/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;
as well as URLs for NNTP newsgroup(s).