Re: [PATCH 2/4] stubdom: remove pciutils

On 18.08.2026 23:40, Samuel Thibault wrote:
> Jan Beulich, le mar. 18 août 2026 08:03:51 +0200, a ecrit:
>> On 17.08.2026 18:37, Samuel Thibault wrote:
>>> Juergen Gross, le lun. 17 août 2026 10:24:02 +0200, a ecrit:
>>>> On 17.08.26 09:48, Samuel Thibault wrote:
>>>>> Juergen Gross, le lun. 17 août 2026 09:18:41 +0200, a ecrit:
>>>>>> There is no user of libpci left in stubdoms.
>>>>>>
>>>>>> Remove libpci from the stubdom build system.
>>>>>
>>>>> Wouldn't it be useful to keep this for anybody who would want to drive a
>>>>> PCI card from a stubdomain?
>>>>>
>>>>> I mean, in the zlib case, it's really a mere question of build & link,
>>>>> so we don't need to ship it, people can do it themselves easily like for
>>>>> any other library.
>>>>>
>>>>> But here there is actual porting work, that we'd better not lose but
>>>>> keep shipping.
>>>>
>>>> This is all still available via git.
>>>
>>> No, it is not really.
>>
>> Question is - does this matter in the first place? If someone wanted to
>> drive e.g. a USB device, would we include USB code?
> 
> Why not? I mean, better centralize the maintenance of such code instead
> of possibly several people having to maintain their own USB layer each.

Well, but where would you stop then? We can't provide for everything. And
apart from "everything", "nothing" is the only other clear boundary to
possibly use.

>> I'm with Jürgen that we should have in the upstream tree only what is
>> also used in-tree.
> 
> But then there's probably quite a few things that could be dropped
> from mini-os because the mini-os and xen trees don't use them, e.g.
> the fbfront. But is that really a service to make to people using this
> infrastructure, or planning to?

fbfront is local code of ours, not something we pull in. IOW I don't think
that's valid to use for comparison here.

Jan