All of lore.kernel.org
 help / color / mirror / Atom feed
From: Detlev Zundel <dzu@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 0/2] api: extend accessible set of block device attributes
Date: Mon, 24 Oct 2011 11:32:44 +0200	[thread overview]
Message-ID: <m2r522ohtv.fsf@ohwell.denx.de> (raw)
In-Reply-To: <CANJuy2LDoPtHC_37=rkR3pvHmPFJvUnsM+==YxgaDpVoo5sT1A@mail.gmail.com> (Che-liang Chiou's message of "Mon, 24 Oct 2011 11:36:50 +0800")

Hi Che-liang,

> I am working on an open source secure bootloader based on U-Boot.
> Mostly I wrote boot logic (by boot logic I mean prompting user and
> listing available devices sort of things). If you see U-Boot as a
> platform, you can think of my project as an application running on top
> of U-Boot, except that my application is statically linked with
> U-Boot.

Usually the (old or new) API is used to separate the application from
the GPLed U-Boot codebase to allow for proprietary applications.  If you
plan to link your application statically to U-Boot anyway, then I think
that using the (external) API is not a good way to move forward.

> The boot logic is running on ARM and x86. Through the project I have
> learned that certain APIs would be helpful, such as enumerating all
> available block device and drawing bitmaps on screen regardless of
> which driver (video or LCD) you are using.

Yes, I think what you actually are looking for is a proper device model
in U-Boot.  Actually we are in dire need for something like this in the
whole of U-Boots codebase and we talk about it for a very long time (see
for example [1]).  This would ease progress in multiple
areas, where currently we hack around this.  See for example the
SERIAL_MULTI code base or NET_MULTI.  Both are isolated solutions for
the same problem.  As you note, video and block devices will also
profit - USB will be another instance.

> It was probably a misleading finding when I searched the code base: I
> saw only the external apps API implemented an API for enumerating
> available block device. So I thought improving the external apps API
> was the right place to go.
>
> Alternatively (if not go the external apps API), we could have like
> common/cmd_enum_block_dev.c that does what I am planning to do, and I
> am happy to do this. What do you think?

I think we should aim at a pretty generic device interface.  Currently I
would think that this also needs to fit into the "configure U-Boot
through the device tree" topic.  The one will profit from the other.

As far as I know, Marek (on CC) is working towards this device tree
model also.  Coordinating the efforts will be a good thing.

Thanks!
  Detlev

-- 
Perfecting oneself is as much unlearning as it is learning. 
                                        -- Edsger Dijkstra 
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

      reply	other threads:[~2011-10-24  9:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-21  6:31 [U-Boot] [PATCH 0/2] api: extend accessible set of block device attributes Che-Liang Chiou
2011-10-21  6:31 ` [U-Boot] [PATCH 1/2] Flatten and solidify block_dev_desc layout Che-Liang Chiou
2011-10-21 19:09   ` Wolfgang Denk
2011-10-24  3:36     ` Che-liang Chiou
2011-10-24 10:49       ` Detlev Zundel
2011-10-21  6:31 ` [U-Boot] [PATCH 2/2] api: storage: Share attributes with block_dev_desc Che-Liang Chiou
2012-01-08  7:26   ` Mike Frysinger
2011-10-21  7:03 ` [U-Boot] [PATCH 1/2] Flatten and solidify block_dev_desc layout Che-Liang Chiou
2011-10-21 16:06 ` [U-Boot] [PATCH 0/2] api: extend accessible set of block device attributes Detlev Zundel
2011-10-24  3:36   ` Che-liang Chiou
2011-10-24  9:32     ` Detlev Zundel [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=m2r522ohtv.fsf@ohwell.denx.de \
    --to=dzu@denx.de \
    --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 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.