[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Seeking recommendations wrt. target-specific packages



On Wed, Jun 15, 2016 at 4:59 AM, J.T. Conklin wrote:

> I apologize for my earlier explanation.  Unfortunately I still have to
> be somewhat guarded, as there are folks who think the most important
> part of this project is the press release that will announce this to the
> world, fully formed, like Venus on a half shell (needless to say, we
> don't really "get" open source). But I'll do my best to provide more
> details within the constraints I have today.

In that case, your lack of specificity seems reasonable but it would
have been good to know about those constraints up-front.

> We produce network equipment devices, and the project to be released is
> a framework to configure and manage the data plane.

FYI that sounds a bit related to several Debian derivatives:

https://wiki.debian.org/Derivatives/Census/CumulusLinux
https://wiki.debian.org/Derivatives/Census/OpenNetworkLinux
https://wiki.debian.org/Derivatives/Census/VyOS

You might find they have solutions to the problem already. For example
Cumulus recently announced their system now supports multiple silicon
vendors as they added Mellanox in addition to the initial Broadcom
support.

https://cumulusnetworks.com/blog/silicon-choices/
https://cumulusnetworks.com/cumulus-linux/overview/

> There are three classes of components/packages. The first are completely
> target-independent, the second are dependent on specific NPU hardware,
> the third is tied to a specific hardware model.
>
> So suppose there were three devices the X100, X200, and X300.  The X100
> and X200 have a NPU from vendor B, the X300 has a NPU from vendor M. All
> three devices have the CPU architecture, so they all use common packages
> for components of the first type. The X100 and X200 use the same driver
> packages for NPU B, but the X300 uses a corresponding drivers for NPU M.
> And each device has a set of packages with config files, etc. that are
> specific for that specific hardware model.
>
> Our hope is that when a user/admin installs the toplevel framework
> package, only the appropriate NPU driver and target-specific packages
> would be installed. For example, a user with an X100 wouldn't get the
> X300 NPU driver and the X200 target-specific packages.

Personally I would suggest installing all the drivers/configs and
deferring loading of drivers/configs to runtime. This has the
advantage that you can move your install around and it will still
work. This has the disadvantage of more disk usage and
complexity/resources to do the detection.

AFAIK apt doesn't know about the hardware it is running on so it needs
something external to point users at hardware-specific packages.

There are some options for that:

Modify the install system that you use to check for the device and
install the appropriate packages. If you are using the Debian
installer, hw-detect package appears to be the place to do that (grep
for the apt-install commands):

https://tracker.debian.org/pkg/hw-detect
https://anonscm.debian.org/cgit/d-i/hw-detect.git

Add the appropriate meta-data to the relevant packages and configure
your install method to use isenkram to install hardware-specific
packages:

http://planet-search.debian.org/cgi-bin/search.cgi?terms=isenkram
https://tracker.debian.org/pkg/isenkram
https://anonscm.debian.org/cgit/collab-maint/isenkram.git

If you are just using debootstrap for installs, hard-code the relevant
packages into the debootstrap wrapper you use.

Another approach would be to add meta-packages for each device
depending on the right packages and have one of the mechanisms above
install just those meta-packages.

> As Rebecca Palmer pointed out, there are some parallels with X11 and GPU
> drivers to what we are trying to do.

In Debian the xserver-xorg-video-* packages are only installed via
xserver-xorg-video-all (task-desktop depends on it), which means that
every system has support for any driver and the appropriate driver is
detected and loaded at runtime. For video drivers this is a good idea
since it means you can move the hard drive to another computer and you
will still be able to use the GUI.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


Reply to: