On Fri, Jun 19, 2026 at 01:25:18PM +0530, Anshu Kumari wrote:
> On Fri, Jun 19, 2026 at 9:24 AM David Gibson <david@gibson.dropbear.id.au>
> wrote:
> 
> > On Wed, Jun 17, 2026 at 06:52:36PM +0530, Anshu Kumari wrote:
[snip]
> > > @@ -178,17 +243,25 @@ static int fill(struct msg *m)
> > >        * Put it there explicitly, unless requested via option 55.
> > >        */
> > >       if (opts[55].clen > 0 && !memchr(opts[55].c, 53, opts[55].clen))
> > > -             fill_one(m->o, OPT_MAX, 53, &offset);
> > > +             fill_one(m->o, size, 53, &offset);
> > >
> > >       for (i = 0; i < opts[55].clen; i++) {
> > >               o = opts[55].c[i];
> > >               if (opts[o].slen != -1)
> > > -                     fill_one(m->o, OPT_MAX, o, &offset);
> > > +                     fill_one(m->o, size, o, &offset);
> > >       }
> > >
> > >       for (o = 0; o < 255; o++) {
> > >               if (opts[o].slen != -1 && !opts[o].sent)
> > > -                     fill_one(m->o, OPT_MAX, o, &offset);
> > > +                     fill_one(m->o, size, o, &offset);
> > > +     }
> > > +
> > > +     *overload = fill_overflow(m, has_bootfile);
> >
> > Is there a particular reason to put fill_overflow() in its own
> > function, rather than just inline here?
> >
> 
> There is no particular reason. I just thought it would be better to
> have a separate function for option overload (may be for better
> clarity).

Ok.  I think the overall flow - try to fill this field, then this
field, then this field - would be a bit clearer if it were inline.
Not a big deal though.

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson