Page MenuHomeFreeBSD

multimedia/webcamd: Update for ino64
AbandonedPublic

Authored by hselasky on May 18 2017, 3:16 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mar 16 2024, 11:13 PM
Unknown Object (File)
Mar 3 2024, 11:40 PM
Unknown Object (File)
Feb 17 2024, 10:52 PM
Unknown Object (File)
Feb 11 2024, 9:47 AM
Unknown Object (File)
Dec 23 2023, 4:42 PM
Unknown Object (File)
Dec 20 2023, 12:48 AM
Unknown Object (File)
Dec 10 2023, 6:39 PM
Unknown Object (File)
Oct 10 2023, 6:38 PM

Details

Reviewers
kib
Group Reviewers
portmgr
Summary

This change adopts the port to ino64 commit, which is explained in
https://lists.freebsd.org/pipermail/freebsd-current/2017-April/065687.html
The src change is nearly ready to commit, and is undergoing a final round
of pre-commit testing. This will likely happen in the next few days,
unless some issue found.

In general, patches for ino64 support will be conditional on FreeBSD
version. It is likely that __FreeBSD_version / kern.osreldate 1200031
will be the value used for the ino64 change, and the port patch may have
a conditional test using that value. Of course, if the final value in
the src commit is different the ports patches will be updated before
commit.

A number of ports require updates after this change is committed to src.
I seek approval of the change to the port in this review, either directly
from the maintainer or portmgr blanket approval of the set of ino64 port
updates. In either case I will commit the ports change shortly after the
src tree commit.

I am also happy if you, as maintainer of the port, wish to handle this
yourself. Please add a comment here with your preference for this port.

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

@kib

Is the patch written in a way that it can be used when the inode size is 32-bit ?

Or are ifdefs needed ?

--HPS

@kib

Is the patch written in a way that it can be used when the inode size is 32-bit ?

Or are ifdefs needed ?

Patch is conditionally applied only when base has ino64 changes.

Why does webcamd sources (re)define dev_t ? If not this issue, patch could be applied unconditionally. In other words, you can take kernel/linux_func.c chunks and apply them to your source. kernel/linux_defs.h must be only applied on ino64, unless dev_t redefinition can be avoided.

Hi,

dev_t is used in conjunction with MKDEV() which is 32-bit. Did you test if webcamd breaks w/o this patch or is this patch a simple result of "grep -r" ? The dev_t should not be used in any FreeBSD kernel interfaces, only Linux ones.

--HPS

dev_t is used in conjunction with MKDEV() which is 32-bit. Did you test if webcamd breaks w/o this patch or is this patch a simple result of "grep -r" ? The dev_t should not be used in any FreeBSD kernel interfaces, only Linux ones.

This patch is result of fixing the build failure. I have no intend, nor I have any setup, to test webcamd at runtime.

Linux defines dev_t like this, and I think webcamd wants to keep it 32-bit.

include/linux/types.h:typedef u32 kernel_dev_t;
include/linux/types.h:typedef __kernel_dev_t dev_t;

Is it impossible to have webcamd define its own dev_t due to the header file pollution made by the ino64 patch?

Linux defines dev_t like this, and I think webcamd wants to keep it 32-bit.

include/linux/types.h:typedef u32 kernel_dev_t;
include/linux/types.h:typedef __kernel_dev_t dev_t;

Is it impossible to have webcamd define its own dev_t due to the header file pollution made by the ino64 patch?

ino64 patch does not introduce any header pollution.

hselasky abandoned this revision.
hselasky edited reviewers, added: kib; removed: hselasky.

I'll roll out a new version of webcamd which works with both 32 and 64 bit sized dev_t .