On 16:42 Sat 08 Sep , Jean-Christophe PLAGNIOL-VILLARD wrote:
> 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@xxxxxxxxxxxx>
> > > > >
> > > > > 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
reply to the wrong e-mail
Best Regards,
J.
_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
