[PATCH 09/11] defaultenv-2: boot/net add bootp support
Jean-Christophe PLAGNIOL-VILLARD
plagnioj at jcrosoft.com
Sat Sep 8 10:42:03 EDT 2012
On 15:47 Sat 08 Sep , Sascha Hauer wrote:
> On Sat, Sep 08, 2012 at 08:17:30AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 07:40 Sat 08 Sep , Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > On 20:21 Fri 07 Sep , Sascha Hauer wrote:
> > > > On Fri, Sep 07, 2012 at 02:13:35PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > > Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> > > >
> > > > Given that the bootp support seems to have nearly nothing in common
> > > > with the boot/net file wouldn't it be better to just add a new file
> > > > boot/bootp?
> > > why not with the boot sequence we can do so
> > I try to implement it but at the end we duplicate it
> > As we may want to just pass the rootpath via bootp
> >
> > and the reset hardcoded
> >
> > It's better to keep it's support in the same file as the static params are
> > fallback one
>
> I really don't like the approach at all.
>
> The current /env/boot/* scripts are written with the intention that they
> should be simple scripts which are easily adjustable. They are also
> meant as templates to add other board/company/project specific files.
>
> Now it only takes one patch series to turn them into complex scripts
> which after staring at them for half an hour I still not fully
> understand. I don't understand why this must be so, because it seems
> what the scripts do is a complex way of saying:
>
> path=/mnt/tftp
> global.bootm.image="${path}/${global.dhcp.bootfile}"
> global.bootm.oftree="${path}/${global.dhcp.oftree_file}"
> nfsroot="${global.dhcp.rootpath}"
> bootargs-ip
> bootargs-root-nfs -n "$nfsroot"
>
> Since you introduced a boot sequence support it should be easy to try
> bootp like above and fall back to the regular net boot if it fails.
the issue with nfs is the mount path
you need to mount `dirname file`
but if the file is a symlink this is where it's complex you need to resolv it
and mount the real path
I'd prefer to avoid it but nfs is like this
as you may just be allow to see a part of the host tree via nfs and the host
have different mountpoint
Best Regards,
J.
More information about the barebox
mailing list