public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 3/3] efi_loader: remove block device details from efi file
Date: Thu, 10 Jan 2019 15:36:24 +0900	[thread overview]
Message-ID: <20190110063623.GC20286@linaro.org> (raw)
In-Reply-To: <d3fc3826-8f68-119f-3cf3-d0439e92268b@suse.de>

On Thu, Jan 10, 2019 at 07:22:49AM +0100, Alexander Graf wrote:
> 
> 
> On 10.01.19 01:37, AKASHI Takahiro wrote:
> > Alex,
> > 
> > On Wed, Jan 09, 2019 at 10:18:16AM +0100, Alexander Graf wrote:
> >>
> >>
> >> On 15.11.18 05:58, AKASHI Takahiro wrote:
> >>> Logically, details on u-boot block device used to implement efi file
> >>> protocol are mostly unnecessary, as well as being duplicated, in
> >>> efi_file structure.
> >>> Moreover, a newly introduced flag, _EFI_DISK_FLAG_INVALID, should be
> >>> honored in any file operations via efi file protocol.
> >>> These observation suggests that those internal details be set behind
> >>> efi_disk object.
> >>>
> >>> So rework in this patch addresses all those issues above although
> >>> there is little change in its functionality.
> >>>
> >>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> >>> ---
> >>>  include/efi_loader.h      |  6 +++++-
> >>>  lib/efi_loader/efi_disk.c | 38 ++++++++++++++++++++++++++++++++++++--
> >>>  lib/efi_loader/efi_file.c | 21 ++++++++-------------
> >>>  3 files changed, 49 insertions(+), 16 deletions(-)
> >>>
> >>> diff --git a/include/efi_loader.h b/include/efi_loader.h
> >>> index 3bae1844befb..108ef3fe52ee 100644
> >>> --- a/include/efi_loader.h
> >>> +++ b/include/efi_loader.h
> >>> @@ -264,6 +264,10 @@ efi_status_t efi_disk_register(void);
> >>>  bool efi_disk_is_valid(efi_handle_t handle);
> >>>  /* Called by bootefi to find and update disk storage information */
> >>>  efi_status_t efi_disk_update(void);
> >>> +/* Called by file protocol to set internal block io device */
> >>> +int efi_disk_set_blk_dev(efi_handle_t disk);
> >>> +/* Called by file protocol to get disk/partition information */
> >>> +int efi_disk_get_info(efi_handle_t disk, disk_partition_t *part);
> >>>  /* Create handles and protocols for the partitions of a block device */
> >>>  int efi_disk_create_partitions(efi_handle_t parent, struct blk_desc *desc,
> >>>  			       const char *if_typename, int diskid,
> >>> @@ -355,7 +359,7 @@ void efi_signal_event(struct efi_event *event, bool check_tpl);
> >>>  
> >>>  /* open file system: */
> >>>  struct efi_simple_file_system_protocol *efi_simple_file_system(
> >>> -		struct blk_desc *desc, int part, struct efi_device_path *dp);
> >>> +		efi_handle_t disk);
> >>>  
> >>>  /* open file from device-path: */
> >>>  struct efi_file_handle *efi_file_from_path(struct efi_device_path *fp);
> >>> diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
> >>> index 0c4d79ee3fc9..180e8e10bb28 100644
> >>> --- a/lib/efi_loader/efi_disk.c
> >>> +++ b/lib/efi_loader/efi_disk.c
> >>> @@ -9,6 +9,7 @@
> >>>  #include <blk.h>
> >>>  #include <dm.h>
> >>>  #include <efi_loader.h>
> >>> +#include <fs.h>
> >>>  #include <part.h>
> >>>  #include <malloc.h>
> >>>  
> >>> @@ -254,6 +255,40 @@ efi_fs_from_path(struct efi_device_path *full_path)
> >>>  	return handler->protocol_interface;
> >>>  }
> >>>  
> >>> +/*
> >>> + * Set block device for later block io's from file system protocol
> >>> + *
> >>> + * @disk	handle to uefi disk device
> >>> + * @return	0 for success, -1 for failure
> >>> + */
> >>> +int efi_disk_set_blk_dev(efi_handle_t disk)
> >>> +{
> >>> +	struct efi_disk_obj *diskobj;
> >>> +
> >>> +	diskobj = container_of(disk, struct efi_disk_obj, header);
> >>> +
> >>> +	return fs_set_blk_dev_with_part(diskobj->desc, diskobj->part);
> >>> +}
> >>> +
> >>> +/*
> >>> + * Get disk/partition information
> >>> + *
> >>> + * @disk	handle to uefi disk device
> >>> + * @part	pointer to disk/partition information to be returned
> >>> + * @return	0 for success, -1 for failure
> >>> + */
> >>> +int efi_disk_get_info(efi_handle_t disk, disk_partition_t *part)
> >>> +{
> >>> +	struct efi_disk_obj *diskobj;
> >>> +
> >>> +	diskobj = container_of(disk, struct efi_disk_obj, header);
> >>> +
> >>> +	if (diskobj->part >= 1)
> >>> +		return part_get_info(diskobj->desc, diskobj->part, part);
> >>> +	else
> >>> +		return part_get_info_whole_disk(diskobj->desc, part);
> >>> +}
> >>> +
> >>>  /*
> >>>   * Create a handle for a partition or disk
> >>>   *
> >>> @@ -308,8 +343,7 @@ static efi_status_t efi_disk_add_dev(
> >>>  	if (ret != EFI_SUCCESS)
> >>>  		return ret;
> >>>  	if (part >= 1) {
> >>> -		diskobj->volume = efi_simple_file_system(desc, part,
> >>> -							 diskobj->dp);
> >>> +		diskobj->volume = efi_simple_file_system(&diskobj->header);
> >>>  		ret = efi_add_protocol(&diskobj->header,
> >>>  				       &efi_simple_file_system_protocol_guid,
> >>>  				       diskobj->volume);
> >>> diff --git a/lib/efi_loader/efi_file.c b/lib/efi_loader/efi_file.c
> >>> index beb4fba917d8..944383224f30 100644
> >>> --- a/lib/efi_loader/efi_file.c
> >>> +++ b/lib/efi_loader/efi_file.c
> >>> @@ -17,9 +17,7 @@ const efi_guid_t efi_file_system_info_guid = EFI_FILE_SYSTEM_INFO_GUID;
> >>>  
> >>>  struct file_system {
> >>>  	struct efi_simple_file_system_protocol base;
> >>> -	struct efi_device_path *dp;
> >>> -	struct blk_desc *desc;
> >>> -	int part;
> >>> +	efi_handle_t disk;
> >>
> >> Is there a particular reason we can't just make this a struct
> >> efi_disk_obj *?
> > 
> > Just because efi_disk_obj is an internally-defined structure in efi_disk.c.
> > 
> >> Inside our own code base, we don't need to abstract things away to
> >> handles, right? We also want to have the compiler catch the fact early
> >> if people pass in non-disk-objects in as parameter.
> > 
> > If you don't mind efi_disk_obj definition being moved to, say, efi_loader.h,
> > I would follow your suggestion.
> 
> I don't think we need to move the definition, just the hint that the
> name exists.
> 
> If you add the following to efi_loader.h:
> 
>   struct efi_disk_obj;

> that should be enough to enable other subsystems (and APIs) to use
> pointers to that struct.

Ah, right. What we need to have in struct file_system is a *pointer*.
So such a declaration is good enough.

Thanks,
-Takahiro Akashi
> 
> 
> Alex

      reply	other threads:[~2019-01-10  6:36 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-15  4:58 [U-Boot] [PATCH v2 0/3] efi_loader: add removable device support AKASHI Takahiro
2018-11-15  4:58 ` [U-Boot] [PATCH v2 1/3] efi_loader: export efi_locate_handle() function AKASHI Takahiro
2018-11-15  4:58 ` [U-Boot] [PATCH v2 2/3] efi_loader: enumerate disk devices every time AKASHI Takahiro
2018-12-11 19:55   ` Heinrich Schuchardt
2018-12-13  7:58     ` AKASHI Takahiro
2019-01-09  1:05       ` AKASHI Takahiro
2019-01-09  9:06       ` Alexander Graf
2019-01-10  2:13         ` AKASHI Takahiro
2019-01-10  6:21           ` Alexander Graf
2019-01-10  7:26             ` AKASHI Takahiro
2019-01-10  7:30               ` Alexander Graf
2019-01-10  8:02                 ` AKASHI Takahiro
2019-01-10  8:15                   ` Alexander Graf
2019-01-10  9:16                     ` AKASHI Takahiro
2019-01-10  9:22                       ` Alexander Graf
2019-01-10 19:22                         ` Heinrich Schuchardt
2019-01-11  5:08                           ` AKASHI Takahiro
2019-01-11  4:29                         ` AKASHI Takahiro
2019-01-11  7:57                           ` Alexander Graf
2019-01-12 21:32                             ` Simon Glass
2019-01-12 22:00                               ` Alexander Graf
2019-01-16 21:34                                 ` Simon Glass
2019-01-22  8:29                             ` AKASHI Takahiro
2019-01-22  9:08                               ` Alexander Graf
2019-01-22 19:39                                 ` Simon Glass
2019-01-22 21:04                                   ` Heinrich Schuchardt
2019-01-23  8:06                                     ` AKASHI Takahiro
2019-01-23 21:58                                     ` Simon Glass
2019-01-24  0:53                                       ` AKASHI Takahiro
2019-01-24 20:18                                         ` Simon Glass
2019-01-24 21:19                                           ` Heinrich Schuchardt
2019-01-25  2:27                                             ` AKASHI Takahiro
2019-01-23  9:51                                   ` Alexander Graf
2019-01-23 22:01                                     ` Simon Glass
2019-01-25  8:27                                     ` AKASHI Takahiro
2019-01-25  8:52                                       ` Alexander Graf
2019-01-25  9:18                                         ` AKASHI Takahiro
2019-01-25  9:31                                           ` Alexander Graf
2019-01-28  8:56                                             ` AKASHI Takahiro
2019-01-28  9:36                                               ` Alexander Graf
2019-01-29  0:46                                               ` Simon Glass
2019-01-29  1:22                                                 ` AKASHI Takahiro
2019-01-23  8:12                                 ` AKASHI Takahiro
2019-01-23  9:30                                   ` Alexander Graf
2019-01-10 12:57         ` Simon Glass
2019-01-11  4:51           ` AKASHI Takahiro
2019-01-11  8:00             ` Alexander Graf
2019-01-11 13:03               ` Mark Kettenis
2018-11-15  4:58 ` [U-Boot] [PATCH v2 3/3] efi_loader: remove block device details from efi file AKASHI Takahiro
2019-01-09  9:18   ` Alexander Graf
2019-01-10  0:37     ` AKASHI Takahiro
2019-01-10  6:22       ` Alexander Graf
2019-01-10  6:36         ` AKASHI Takahiro [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=20190110063623.GC20286@linaro.org \
    --to=takahiro.akashi@linaro.org \
    --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