From: Sascha Hauer <s.hauer@pengutronix.de>
To: Yegor Yefremov <yegorslists@googlemail.com>
Cc: barebox <barebox@lists.infradead.org>
Subject: Re: Linux headers
Date: Tue, 26 Jan 2016 22:41:28 +0100 [thread overview]
Message-ID: <20160126214128.GC13058@pengutronix.de> (raw)
In-Reply-To: <CAGm1_ksgdg933-MmgmX7a3H2m5HPf-y+pdZybX9+ahLEA_J+tg@mail.gmail.com>
Hi Yegor,
On Tue, Jan 26, 2016 at 04:17:39PM +0100, Yegor Yefremov wrote:
> AFAIK include/linux/barebox-wrapper.h was introduced to simplify Linux
> driver porting. During my current effort to port SquashFS driver I had
> to repeatedly remove such includes like:
>
> #include <linux/vfs.h>
> #include <linux/slab.h>
> #include <linux/vmalloc.h>
> #include <linux/sched.h>
> #include <linux/spinlock.h>
> #include <linux/wait.h>
>
> and so on.
>
> Would it be better to provide such headers even if they would almost
> always include dummy code? Though it would pollute the include folder
> somehow, but it will be easier to port/sync Linux drivers and it will
> help to preserve the structure of this drivers.
>
> What do you think about this?
What would you add to these header files? I mean for spinlock.h it's
clear, it would contain dummy spinlocks. For other files I'm not sure
how much useful stuff we can put in there. For example wait.h contains
much stuff that - when it's used in the code you are porting - cannot
simply be replaced with dummy code but must be handled somehow. So if we
create the Linux header files there should be more gain than only the
ability to keep the include list untouched. I don't know for how many
files this is the case.
Porting over Linux code to barebox is often a balancing act. We can put
much effort into creating header files which make it possible to (almost)
blindly copy over code or we can keenly modify the Linux code to fit
into barebox. One extreme leads to easily portable but probably
inefficient code, the other leads to hard to update but probably better
understandable code. The truth is probably somewhere between both
extremes.
Anyway, to put it short, I think it makes sense to at least move the
stuff we already have in barebox-wrapper.h to their original places.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
prev parent reply other threads:[~2016-01-26 21:41 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-26 15:17 Yegor Yefremov
2016-01-26 21:41 ` Sascha Hauer [this message]
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=20160126214128.GC13058@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=yegorslists@googlemail.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