[Skiboot] [PATCH v1 0/5] New HBRT interfaces

[Daniel M Crowell]

That compile flag is all fine and good to say, but remember who we're 
dealing with here.  Who is going to be building the 'special' versions of 
this interface for thee folks that are using it.  It already takes a bunch 
of extra people to get the specific distro  installed with all of the 
appropriate patches, etc.  Are you going to maintain packages with the 
debug version?  There are already a thousand native Linux commands that 
one can ruin their system with, how is this different?  This requires sudo 
so the admin should know what they are doing and not run random commands. 
Do we really need to protect users from themselves?  99% of users won't 
even know this application exists...

--
Dan Crowell
Senior Software Engineer - Power Systems Enablement Firmware
IBM Rochester: t/l 553-2987
dcrowell at us.ibm.com



From:   Jeremy Kerr <jk at ozlabs.org>
To:     Stewart Smith <stewart at linux.vnet.ibm.com>, Neelesh Gupta 
<neelegup at linux.vnet.ibm.com>, skiboot at lists.ozlabs.org
Cc:     Daniel M Crowell/Rochester/IBM at IBMUS, Bill 
Schwartz/Austin/IBM at IBMUS, Christopher J Cain/Rochester/IBM at IBMUS
Date:   08/12/2015 10:16 PM
Subject:        Re: [Skiboot] [PATCH v1 0/5] New HBRT interfaces



Hi Stewart,


> So, from my understanding the htmgt_pass_thru is strictly for
> manufacturing/debug and this is in no way going to be a stable API?
>
> How can we ensure that we very *very* *VERY* much communicate this?
>
> I'm thinking we perhaps need a
> 
--i-am-part-of-manufacturing-or-acknowledge-that-I-am-about-to-make-my-computer-explode
> switch that *must* be specified before running said commands?

How about we make this a compile-time flag, which removes the 
possibility of invoking these manufacturing/system test commands?

( CFLAGS += -DDANGEROUS )

Distros wouldn't be specifying this, so the standard tools wouldn't 
allow these.

> This all being said, why do we need a passthrough rather than just
> specify the commands that can be sent down?

Because we don't want to couple opal-prd code to the HBRT/HTMGT 
implementation.

Cheers,


Jeremy


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/skiboot/attachments/20150812/fb4c5699/attachment.html>