mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: Alessandro Rubini <rubini-list@gnudd.com>, barebox@lists.infradead.org
Subject: Re: NFSv4 boot support?
Date: Mon, 26 Feb 2024 13:17:59 +0100	[thread overview]
Message-ID: <21c5b3f9-e139-4f96-8eab-b8e68419b8e0@pengutronix.de> (raw)
In-Reply-To: <ZdSu671i2n4RQPoz@arcana.i.gnudd.com>

Hello,

On 20.02.24 14:53, Alessandro Rubini wrote:
>>> This hasn't
>>> seen development activity in 5 years.
>>
>> Please see https://github.com/virtualsquare/picotcp
> 
> But the TCP/IPV4 standard didn't change, either.

I don't mind lack of new features, but I'd prefer that when we
adopt an external network stack, we adopt one that still sees
maintenance and bug fixes. The repository linked by Antony while
having more recent commits, also has a link to security considerations:

https://github.com/virtualsquare/picotcp/blob/master/docs/security.md

which lists 4 year old security issues that are acknowledged, but
unresolved.

>>> lwIP on the other hand still sees active development.
>>
>> I agree with you. It looks like lwIP is more popular than picotcp.
> 
> Sure. It's older and it has a loyal (or addicted) user base and
> commercial support. Or it just needs more commits because it'w worse and
> full of bugs.

Yes, it can go both ways. I am not arguing in favor of comparing
absolute commit count, but I think we might be better off using
a network stack that we don't have to completely maintain ourselves,
given that we already had a network stack that we maintained ourselves
that we are looking to substitute.

In the end, the one who does the work is probably who gets to choose
(and argue their choice).

> As far as I know, lwIP is horrible code, difficult to integrate and
> maintain
Thanks for your input. My only interaction with lwIP so far was some
weekend time spent on integrating it into the barebox build system,
but I haven't went further than that to actually wire it with the network API.

> while picotcp is designed in the right way (although I admit
> I only looked at the former, about picotcp I only talked with the main
> author without looking at the code).

I think best case, we would proceed as suggested by Antony: Rework
the interfaces in barebox, so both the existing network stack and lwIP
(or picotcp) can be integrated using the same APIs.

> I'd love to add mqtt to my microcontroller projects, where I have udp
> but no tcp yet, and I would never rely on lwIP. That's just a personal
> opinion, but I'd better not rely on the date of last commit to pick
> or not pick a library.

Did you try integrating picotcp instead? What issues did you run into?

Thanks,
Ahmad

> 
> Regards
> /alessandro
> 
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |




  reply	other threads:[~2024-02-26 12:18 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-31 21:03 Dan Shelton
2024-01-31 21:37 ` Ahmad Fatoum
2024-02-05  9:59   ` Antony Pavlov
2024-02-17  8:51     ` Ahmad Fatoum
2024-02-19  2:17       ` Dan Shelton
2024-02-20 14:17         ` Ahmad Fatoum
2024-02-20 15:28           ` Uwe Kleine-König
2024-02-19 21:43       ` Antony Pavlov
2024-02-20 13:53       ` Alessandro Rubini
2024-02-26 12:17         ` Ahmad Fatoum [this message]
2024-03-08 10:23         ` Sascha Hauer
2024-03-09 10:01         ` Alessandro Rubini
2024-02-28  7:26       ` Antony Pavlov
2024-02-28  9:20         ` Sascha Hauer
2024-02-28 11:50           ` Antony Pavlov
2024-02-28 12:27             ` Sascha Hauer
2024-02-05 18:41   ` Antony Pavlov
2024-02-06  4:40     ` Dan Shelton

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=21c5b3f9-e139-4f96-8eab-b8e68419b8e0@pengutronix.de \
    --to=a.fatoum@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --cc=rubini-list@gnudd.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