From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/2] Move all command code into its own directory
Date: Tue, 19 Jan 2016 10:53:45 -0500 [thread overview]
Message-ID: <20160119155345.GC3359@bill-the-cat> (raw)
In-Reply-To: <CAK7LNARAYDKq48EPCQdNcRkXyFEJMi3qEQbQq31R=KsjYwSX-g@mail.gmail.com>
On Tue, Jan 19, 2016 at 12:59:10PM +0900, Masahiro Yamada wrote:
> Hi Simon,
>
> 2016-01-18 12:53 GMT+09:00 Simon Glass <sjg@chromium.org>:
> > There are a lot of unrelated files in common, including all of the commands.
> > Moving them into their own directory makes them easier to find and is more
> > logical.
> >
> > Some commands include non-command code, such as cmd_scsi.c. This should be
> > sorted out at some point so that the function can be enabled with or without
> > the associated command.
> >
> > Unfortunately, with m68k I get this error:
> >
> > m68k: + M5329AFEE
> > +arch/m68k/cpu/mcf532x/start.o: In function `_start':
> > +arch/m68k/cpu/mcf532x/start.S:159:(.text+0x452): relocation truncated to fit: R_68K_PC16 against symbol `board_init_f' defined in .text.board_init_f section in common/built-in.o
> >
> > I hope someone can shed some light on what this means. I hope it isn't
> > depending on the position of code in the image.
> >
> > Signed-off-by: Simon Glass <sjg@chromium.org>
>
>
> Thanks for working on this!
>
> This is a nice improvement,
> but we might want to think about the best place for device access commands
> in the future.
>
>
> I mean,
>
> cmd_nand.c in drivers/mtd/nand/ rather than cmd/
> cmd_mmc.c in drivers/mmc/ rather than cmd/
> cmd_usb.c in drivers/usb/ rather thant cmd/
>
> etc.
But we're not going to have anywhere near a 1:1 mapping of commands to
some subdirectories. So I would make the inverse point, we would have
commands in drivers/mtd/nand, drivers/mmc, drivers/usb/host,
drivers/usb/gadget, drivers/dm, board/foo instead of being able to say
"If you add a new command, it goes into cmd/" and similarly, "Did you
see cmd/foo.c? That sound a whole lot like what you're doing in
cmd/fauxoo.c" and possibly even short-circuting that problem at the
design phase when people see that someone else already had a similar
problem and solved it.
> This patch moves cmd_usb.c, but leaves common/usb*.c.
>
> With this patch, USB files are located in three places:
> - cmd/cmd_usb.c
> - common/usb*.c
> - drivers/usb/
>
>
> Is collecting all them into drivers/usb/ more logical?
Skimming common/usb*.c, I think a lot of that needs to move into
drivers/usb/<various dirs>.
> I think this needs closer look and more discussion, though.
I like this approach as it does expose some of the problems with the
current lack-of-structure, ie all of the non-command stuff in the cmd
files, and other things we've shoved into common/ that don't quite
belong there now really. It will also make it easier to split up the
current command files where we have a lot of 'hidden' commands.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160119/a9a74738/attachment.sig>
next prev parent reply other threads:[~2016-01-19 15:53 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-18 3:53 [U-Boot] [PATCH 0/2] Move commands into their own directory Simon Glass
2016-01-18 3:53 ` [U-Boot] [PATCH 1/2] Move all command code into its " Simon Glass
2016-01-18 4:51 ` Bin Meng
2016-01-18 5:38 ` Heiko Schocher
2016-01-18 6:03 ` Stefan Roese
2016-01-18 8:28 ` Przemyslaw Marczak
2016-01-19 3:59 ` Masahiro Yamada
2016-01-19 15:53 ` Tom Rini [this message]
2016-01-20 4:35 ` Simon Glass
2016-01-25 21:28 ` [U-Boot] [U-Boot, " Tom Rini
2016-01-18 3:53 ` [U-Boot] [PATCH 2/2] Remove the cmd_ prefix from command files Simon Glass
2016-01-18 4:51 ` Bin Meng
2016-01-18 5:38 ` Heiko Schocher
2016-01-18 6:04 ` Stefan Roese
2016-01-18 8:29 ` Przemyslaw Marczak
2016-01-25 21:28 ` [U-Boot] [U-Boot, " Tom Rini
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=20160119155345.GC3359@bill-the-cat \
--to=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
/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