[OpenWrt-Devel] [PATCH 3/3] treewide: rename DEVICE_TYPE to DEFAULT_TYPE

[Matthias Schiffer]

On 5/31/20 12:06 AM, Adrian Schmutzler wrote:
> Hi,
> 
>> -----Original Message-----
>> From: openwrt-devel [mailto:openwrt-devel-bounces at lists.openwrt.org]
>> On Behalf Of mans0n
>> Sent: Samstag, 30. Mai 2020 12:20
>> To: 'Matthias Schiffer' <mschiffer at universe-factory.net>;
>> mail at adrianschmutzler.de
>> Cc: 'Linus Walleij' <linus.walleij at linaro.org>; openwrt-
>> devel at lists.openwrt.org
>> Subject: Re: [OpenWrt-Devel] [PATCH 3/3] treewide: rename DEVICE_TYPE
>> to DEFAULT_TYPE
>>
>> Hi Adrian, Matthias,
>>
>> I was preparing my own patch for converting DEVICE_TYPE to a device-
>> specific variable.
>> https://github.com/mans0n/openwrt/commit/4d41dd963ae8d595ef38ea0a3
>> 8ea08abdac1415d
>> But I stumbled on some blockers so I left it behind...
> 
> One of the problems of this approach (changing DEVICE_PACKAGES) is that it
> will only work if CONFIG_TARGET_PER_DEVICE_ROOTFS is set, as only then
> DEVICE_PACKAGES will be evaluated IIRC. So, this won't help for building
> Default Profile and I don't know whether it will work for a single target
> device being selected directly (without Multi Profile).

DEVICE_PACKAGES works fine without multi-profile (in fact, it has existed
for a bit longer than CONFIG_TARGET_PER_DEVICE_ROOTFS).

I don't think we need to care about multi-profile without PER_DEVICE_ROOTFS
- both OpenWrt buildbots and Gluon use PER_DEVICE_ROOTFS. IMO "pultiprofile
without per-device rootfs" and the "default profile" are legacy features
that aren't very useful now that better alternatives exist.

Matthias


> 
> So I don't think this will help for package selection at least.
> 
> Best
> 
> Adrian
> 
>>
>> One of the blockers was the busybox hdparm.
>> I'd also found that DEVICE_TYPE in the busybox Makefile does not work as
>> intended, thanks to Linus for dealing with this.
>>
>>> On 5/29/20 10:52 PM, mail at adrianschmutzler.de wrote:
>>>>> Or we just drop the variable at all, and do DEFAULT_PACKAGES :=
>>>>> DEFAULT_PACKAGES.basic DEFAULT_PACKAGES.router at the beginning
>> (!)
>>>>> of target.mk, so targets (effectively just 3 of them) can just
>>>>> overwrite it with DEFAULT_PACKAGES := DEFAULT_PACKAGES.basic
>>>>> DEFAULT_PACKAGES.nas directly in the few cases where that is
>> necessary (I'd rather use DEFAULT_PACKAGES_BASIC etc. as names then).
>>>>
>>>> I've pushed a quick draft of this approach here:
>>>>
>>>> https://git.openwrt.org/?p=openwrt/staging/adrian.git;a=shortlog;h=re
>>>> fs/heads/devicetypedrop
>>>>
>>>> Only the most topmost patch is relevant. From "make menuconfig" it
>> seems to work as expected.
>>>
>>> I would prefer to find a solution that doesn't require adding
>>> $(DEFAULT_PACKAGES_BASIC) to the other default package lists. I'll
>>> have to ponder over this a bit more. Posting the patch - possibly
>>> marked as [RFC] - would make discussing this easier.
>>>
>>>
>>>>
>>>> The if/else in busybox is not considered in this patch.
>>>>
>>>
>>> Meanwhile I've found another target-specific config setting in the
>>> busybox
>>> package: BUSYBOX_DEFAULT_TRUNCATE is enabled for TARGET_bcm53xx
>> only.
>>>
>>> I assume "truncate" is tiny enough that it doesn't really justify
>>> making busybox non-shared, we could just build in truncate
>>> unconditionally. I don't know how contrained some of the "nas" targets
>>> are, but maybe we should just replace the busybox hack with a
>>> full-featured hdparm on these targets?
>>
>> Busybox hdparm is about 8k and full hdparm is about 93k. I think most NAS
>> devices can manage that space, so I agree with Matthias.
>> But the problem is that full hdparm is in the package feed, so it
> shouldn't be
>> included in DEFAULT_PACKAGES (unless we move the package into the main
>> repo).
>>
>> Now I prefer removing DEVICE_TYPE entirely as Adrian suggested. I can't
> see
>> any use case of it other than package selections.
>> Perhaps we can create some meta packges (only containing dependencies)
>> as an alternative?
>>
>> Thanks.
>>
>>>
>>> Matthias
>>>
>>
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel at lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20200531/04f02237/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel