All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
To: dccp@vger.kernel.org
Subject: Re: unchanged functions between ccid-3 and ccid-4
Date: Fri, 21 Sep 2007 10:00:21 +0000	[thread overview]
Message-ID: <20070921100021.GB2418@ghostprotocols.net> (raw)
In-Reply-To: <5bc4c4570709201928l270b24cdod359349ca3d3508@mail.gmail.com>

Em Thu, Sep 20, 2007 at 11:28:52PM -0300, ツ Leandro Sales escreveu:
> 2007/9/20, Ian McDonald <ian.mcdonald@jandi.co.nz>:
> > On 9/21/07, ツ Leandro Sales <leandroal@gmail.com> wrote:
> > > Hello Gerrit,
> > >
> > >    From now and as I was talking to Ian two days ago, after our
> > > patchset for initial code of ccid-4, I'm identifying functions between
> > > ccid-4 and ccid-3 that will remains unchangeable. What do you think if
> > > we try to define something like a common_ccid34.{c/h} and make common
> > > functions between ccid-4 and ccid-3 available into this source file?
> > > Or this will make the code a little bit confused?
> > >
> > > Leandro.
> > >
> > Leandro,
> >
> > Firstly - I think these discussions are better on list. Can we open to list.
> >
> > Thinking some more about this I've thought about this some more. I
> > think what we're bettter to do is to get CCID4 code to use CCID3 code
> > rather than create a new file. This is because CCID4 references CCID3
> > but not the other way around.
> >
> > It will also be messy if we then get CCID5 etc.
> >
> > So what I suggest you might need to do is shift more ccid3
> > declarations into ccid3.h and included this. It might also need

This part is OK if the functions are really small

> > removal of some static from function declarations and adding of
> > EXPORT_SYMBOL_GPL to existing CCID3 code.

This one is not because then we would have to load ccid3.ko even when
not using ccid3 fully. Conceptually it is better to have a
dccp_ccid3_lib.ko kernel module like we have now for the tfrc equation
and loss interval code, dccp_tfrc_lib.ko. ccid3.ko and
ccid4.ko would require dccp_ccid3_lib.ko.

> > This way you are still sharing code but it is clear CCID4 is based on CCID3.

The scheme I propose also keeps this property.

> Exactly! I was thinking about this since my first patchset sent via an
> URL, where I commented about this. The problem of doing like you
> suggested (move some code from ccid3.c to ccid3.h) is it will require
> an approval about you and the others, such as gerrit and arnaldo, at
> least if this is the right process to follow.

Don't worry too much about "approvals" at this stage, I think you should
do as you think its ok and discuss here mostly aspects of protocol
implementation, i.e. compliancy with the RFCs, etc.

Reorganizing the resulting source code to match Linux kernel guidelines
is something we should try to do from the start, but also should not get
in the way of having code that works first.

> Anyway, I'm already identifying the candidate codes to be shared
> between ccid3 and ccid4 if you didn't this yet. Another option is wait
> for gerrit suggestion on this issue and discuss more about that and
> define a strategy to avoid code repetition.

See? Wait for Gerrit, wait for Arnaldo, reach a consensus on code layout
first... nah, get something that works, when and if people send
suggestions you react, but don't get lack of feedback on these matters
to make you stop coding.

- Arnaldo

  reply	other threads:[~2007-09-21 10:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-21  2:28 unchanged functions between ccid-3 and ccid-4 
2007-09-21 10:00 ` Arnaldo Carvalho de Melo [this message]
2007-09-21 13:20 ` 
2007-09-25  8:52 ` Gerrit Renker
2007-09-26 13:22 ` Tommi Saviranta
2007-09-26 13:33 ` 
2007-09-26 13:45 ` Tommi Saviranta
2007-09-26 13:51 ` 

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=20070921100021.GB2418@ghostprotocols.net \
    --to=acme@ghostprotocols.net \
    --cc=dccp@vger.kernel.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.