[PATCH 09/11] defaultenv-2: boot/net add bootp support

[Jean-Christophe PLAGNIOL-VILLARD]

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 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
reply to the wrong e-mail

Best Regards,
J.