SERIAL_OF_PLATFORM default setting for DT headless systems

[Benjamin Cama]

Le lundi 22 juin 2015 à 18:23 +0000, Jason Cooper a écrit :
> On Mon, Jun 22, 2015 at 07:43:20PM +0200, Benjamin Cama wrote:
> > Le dimanche 21 juin 2015 ?? 22:07 +0200, Andrew Lunn a ??crit :
> > > On Sun, Jun 21, 2015 at 07:36:04PM +0200, Benjamin Cama wrote:
> > > > Le samedi 20 juin 2015 ?? 16:36 +0200, Andrew Lunn a ??crit :
> > > > > > 
> > > > > > > SERIAL_OF_PLATFORM?
> > > > > > 
> > > > > > Oh, and that was it!
> > > > > 
> > > > > This used to catch us all out a lot. What configuration are you using?
> > > > > orion5x_defconfig? Very likely a patch adding it to that would be
> > > > > accepted.
> > > > 
> > > > None. Sorry, I am used to the x86 world where I almost never used
> > > > default configs (and it's been a long time, too). I admit I never fully
> > > > understood the logic behind the defconfigs, apart from it meaning some
> > > > kind of ???less important??? dependency on some specific options. Shouldn't
> > > > the main UART be a ???hard??? dependency on every board?!
> > > 
> > > You say you are from the x86 world. When did you last use a serial
> > > console on an x86?
> > 
> > Almost daily on my headless VMs ;-) But more seriously, yes, this is
> > very uncommon today. But on x86 you have virtual terminals on your
> > graphic output; NAS boxes don't have them (well, maybe some high-end
> > model, but it is uncommon).
> > 
> > > Anyway, the thinking at the time was that for most
> > > NAS boxes, there is no DB-9 on the back. You have to open up the case,
> > > and connect to a header, or even solder wires to the board, in order
> > > to use a TTL-Serial converter. Very few people actually do that, so
> > > why make the kernel a bit bigger?
> > 
> > Is this really a size problem? Because having a serial port on a
> > *headless* machine is the most useful thing I can think of. So, to me,
> > this option should definitely be activated on headless systems by
> > default, even if the kernel grows a bit because of it. But I agree that
> > it is useless without some advanced access to the serial port, which is
> > not very common. OTOH, I think only people who have such access run non
> > -stock kernels (i.e. the very one we are integrating right here,
> > because vendors don't care after they shipped their device).
> > 
> > > But we have moved on since then, mostly because we ourselves have
> > > forgotten this option too many times. We have SERIAL_OF_PLATFORM
> > > enabled in the _defconfig.
> > 
> > That is nice to have it in the defconfig, thanks for that. But I really
> > think one should consider again having some dependency on it for some
> > headless platforms. I would really like to have other arguments against
> > my view apart from size problems.
> 
> Well, it really comes down to the roles for Kconfig vice defconfigs.  If
> we say a driver or a board 'selects' or 'depends' on something, then we
> are saying either "The build will break without it", or "The board will
> fail to boot without it".  Neither is true for SERIAL_OF_PLATFORM.

OK, I get that.

> The defconfigs have a much looser accepted definition of "a generally
> minimal, but useful set of features for an SoC, platform or
> multi-platform".

OK. That is the difference I was trying to understand when talking
about “hard” or “less important” dependency. Now I understand what are
the Kconfigs about: just the minimal stuff.

> Since the Kconfigs make something a hard requirement for *all* users, we
> try to avoid setting those unless necessary.  I know I can't predict all
> the various usecases for an arm kernel, so we try to avoid forcing
> decisions on users.
>
> The defconfigs fill the gap nicely because a user can start with a
> defconfig, then enable/disable features according to their specific
> use-case.

OK, I get the idea of their use. The assumption I had about defconfig
was right, but I didn't know the Kconfig was the absolute minimal
stuff; I thought it was maybe some “good default without too much
cruft”, but I was wrong.

> As for arguments other than size (which I think is a good one, but
> still), I like security posture.  I have implemented several systems,
> where the design criteria was to remove everything not actually in use.
> The serial port driver was one of many features removed from the system.
> The physical serial port remained if we needed to run the debug image on
> a board.  If SERIAL_OF_PLATFORM was a depend, then I would have had to
> carry yet another patch outside of mainline.

Thanks for pointing that out, too, I hadn't think of it. And sorry if I
sounded too assertive.

Thanks again for the very good explanation,
--
benjamin