[gPXE-devel] [PATCH] EFI Simple Network Protocol driver

[Geoff Lywood]

Back to the main issue at hand: are you satisfied with how my patch looks? Anything I need to fix up so that it can get committed?

Thanks,
Geoff

> -----Original Message-----
> From: Michael Brown [mailto:mbrown at fensystems.co.uk]
> Sent: Tuesday, June 01, 2010 3:01 PM
> To: Geoff Lywood
> Cc: gpxe-devel at etherboot.org
> Subject: Re: [gPXE-devel] [PATCH] EFI Simple Network Protocol driver
> 
> On Tuesday 01 Jun 2010 19:56:58 Geoff Lywood wrote:
> > I don't think that it is possible to use OpenProtocol for the
> >  EFI_CPU_ARCH_PROTOCOL because you never know which handle to use.
> Having
> >  said that, I don't think the EFI_CPU_ARCH_PROTOCOL is defined in the
> UEFI
> >  spec and it may not be guaranteed to exist on all platforms. The "right
> >  thing" is probably to use boot services instead, but comments in the
> code
> >  hint that doing so may not always work? (Can you use a high frequency
> >  timer and increment a tick count yourself?)
> 
> We could use boot services to set up a recurring timer; it wouldn't need
> to be
> high frequency.  (currticks() on PC BIOS has a resolution of only 18Hz.)
> It
> would require a startup and shutdown function in efi_timer.c, but I think
> it
> should work.
> 
> > For the PCI and I/O protocols, I think that the network driver is
> generally
> >  expected to do all accesses through the EFI_PCI_IO_PROTOCOL attached to
> >  the handle for the network device, which you already open BY_DRIVER in
> >  efi_snp_netdev. Currently the wiring isn't in place to keep it open and
> >  have all config space, I/O and memory accesses go through it. I don't
> see
> >  how that will be possible without some major rearchitecture: every
> >  inb/outb in every driver would have to pass a device handle as a second
> >  argument.
> 
> Yes; it was a deliberate design decision on my part not to break the
> fundamental model of memory-mapped I/O when adding EFI support.  (The
> EFI_PCI_IO_PROTOCOL is one of the worst abstraction designs I've seen in
> any
> code anywhere; it pretends that memory-mapped I/O doesn't exist, and is
> about
> as sensible as having an EFI_ADD_OR_SUBTRACT_PROTOCOL for performing basic
> arithmetic operations.)
> 
> Michael