Re: DTrace: Where do we run CTFCONVERT for kernel modules
Quoting Shrikanth Kamath shrikant...@gmail.com (from Sun, 26 Feb
2012 13:24:19 +0530):
...meaning, I see the following line in sys/conf/kmod.mk, but that
is a CTFMERGE command.
.if defined(MK_CTF) ${MK_CTF} != no
${CTFMERGE} ${CTFFLAGS} -o ${.TARGET} ${OBJS}
.endif
Where do we run the CTFCONVERT on kernel modules?
It is run from the Makefile of the kernel which is generated by the
config(8) program.
Bye,
Alexander.
--
Whenever I feel like exercise, I lie down until the feeling passes.
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
DTrace: Where do we run CTFCONVERT for kernel modules
...meaning, I see the following line in sys/conf/kmod.mk, but that
is a CTFMERGE command.
.if defined(MK_CTF) ${MK_CTF} != no
${CTFMERGE} ${CTFFLAGS} -o ${.TARGET} ${OBJS}
.endif
Where do we run the CTFCONVERT on kernel modules?
--
Shrikanth R K
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Checking for other kernel modules on load
On Thu, Dec 29, 2011 at 11:46:57AM +, Chris Rees wrote:
2011/12/28 Kostik Belousov kostik...@gmail.com:
On Wed, Dec 28, 2011 at 02:53:42PM +, Chris Rees wrote:
2011/12/28 Kostik Belousov kostik...@gmail.com:
On Wed, Dec 28, 2011 at 12:23:58PM +, Chris Rees wrote:
On 28 December 2011 12:21, Daniel O'Connor docon...@gsoft.com.au
wrote:
On 28/12/2011, at 22:07, Chris Rees wrote:
Is there a simple way to check for existence of a driver? I could
even check for /dev/sndstat, though that doesn't seem elegant to
me...
kldstat -v, but really /dev/sndstat seems simpler and just as
effective.
Cheers-- I was thinking of a kernel-level function though.
cognet@ suggested using modfind(sound), I'll go with that.
Obvious question is what the panic is. Checking for modules loaded is
papering over some issue.
True, although I figured that it was a simple conflict, possibly to do
with sndstat.
Also, I'm getting panics with the following patch, whether sound is
loaded or not :)
+ if (modfind(sound) = 0)
+ {
+ cmn_err (CE_WARN, A conflicting sound driver is already loaded);
+ return EBUSY;
+ }
+
Is there a better way to handle such conflicts?
You have missed the point. There is some bug in oss driver that causing
the panic. Presumed 'conflict' cannot cause the harm itself, besides not
allowing second driver to attach to the same device, and should not result
in panic. Trying to implement a half-measure that only covers the problem
you do a mis-service.
And you still did not provided the panic message.
I'm sorry, you're right. However, your guess was in fact correct;
make_dev was being called, which returned a null pointer because it
failed.
The patch at [1] stops the panic, however I was hoping that returning
EBUSY would abort loading the module... At the moment it loads the
module, and doesn't create the sndstat dev, which causes weird errors
with the oss binary commands.
Since this solves the panic and anyone should be able to work out from
the warning message what the problem is, AND this is a port that
apparently no-one else uses, should this be sufficient?
BTW, it only affects FreeBSD 9+, couldn't reproduce on my 8.2 dev
machine, but could once I upgraded it.
On 8.2, there is no check in the devfs for duplicated cdev names, AFAIR.
So you get absolutely undeterministic behaviour which driver is referenced
by devfs node.
Chris
[1]
http://www.bayofrum.net/~crees/patches/oss-patch-kernel-OS-FreeBSD-os_freebsd.c
I highly recommend to return error in case of any make_dev_p(9) failure, and
not only EEXIST.
pgpwW0Pqu6gLw.pgp
Description: PGP signature
Re: Checking for other kernel modules on load
2011/12/29 Kostik Belousov kostik...@gmail.com:
On Thu, Dec 29, 2011 at 12:53:19PM +, Chris Rees wrote:
2011/12/29 Kostik Belousov kostik...@gmail.com:
On Thu, Dec 29, 2011 at 11:46:57AM +, Chris Rees wrote:
2011/12/28 Kostik Belousov kostik...@gmail.com:
On Wed, Dec 28, 2011 at 02:53:42PM +, Chris Rees wrote:
2011/12/28 Kostik Belousov kostik...@gmail.com:
On Wed, Dec 28, 2011 at 12:23:58PM +, Chris Rees wrote:
On 28 December 2011 12:21, Daniel O'Connor docon...@gsoft.com.au
wrote:
On 28/12/2011, at 22:07, Chris Rees wrote:
Is there a simple way to check for existence of a driver? I
could
even check for /dev/sndstat, though that doesn't seem elegant to
me...
kldstat -v, but really /dev/sndstat seems simpler and just as
effective.
Cheers-- I was thinking of a kernel-level function though.
cognet@ suggested using modfind(sound), I'll go with that.
Obvious question is what the panic is. Checking for modules loaded is
papering over some issue.
True, although I figured that it was a simple conflict, possibly to do
with sndstat.
Also, I'm getting panics with the following patch, whether sound is
loaded or not :)
+ if (modfind(sound) = 0)
+ {
+ cmn_err (CE_WARN, A conflicting sound driver is already
loaded);
+ return EBUSY;
+ }
+
Is there a better way to handle such conflicts?
You have missed the point. There is some bug in oss driver that causing
the panic. Presumed 'conflict' cannot cause the harm itself, besides not
allowing second driver to attach to the same device, and should not
result
in panic. Trying to implement a half-measure that only covers the
problem
you do a mis-service.
And you still did not provided the panic message.
I'm sorry, you're right. However, your guess was in fact correct;
make_dev was being called, which returned a null pointer because it
failed.
The patch at [1] stops the panic, however I was hoping that returning
EBUSY would abort loading the module... At the moment it loads the
module, and doesn't create the sndstat dev, which causes weird errors
with the oss binary commands.
Since this solves the panic and anyone should be able to work out from
the warning message what the problem is, AND this is a port that
apparently no-one else uses, should this be sufficient?
BTW, it only affects FreeBSD 9+, couldn't reproduce on my 8.2 dev
machine, but could once I upgraded it.
On 8.2, there is no check in the devfs for duplicated cdev names, AFAIR.
So you get absolutely undeterministic behaviour which driver is referenced
by devfs node.
Chris
[1]
http://www.bayofrum.net/~crees/patches/oss-patch-kernel-OS-FreeBSD-os_freebsd.c
I highly recommend to return error in case of any make_dev_p(9) failure,
and
not only EEXIST.
That'd be great-- but I can't work out how to do it :(
Do I need to return a different value?
error = make_dev_p();
if (error != 0) {
printf(Error creating device node /dev/%s: %d\n, name,
error);
return (error);
}
No, that's what I wanted. Thank you.
Chris
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Checking for other kernel modules on load
2011/12/29 Kostik Belousov kostik...@gmail.com:
On Thu, Dec 29, 2011 at 11:46:57AM +, Chris Rees wrote:
2011/12/28 Kostik Belousov kostik...@gmail.com:
On Wed, Dec 28, 2011 at 02:53:42PM +, Chris Rees wrote:
2011/12/28 Kostik Belousov kostik...@gmail.com:
On Wed, Dec 28, 2011 at 12:23:58PM +, Chris Rees wrote:
On 28 December 2011 12:21, Daniel O'Connor docon...@gsoft.com.au
wrote:
On 28/12/2011, at 22:07, Chris Rees wrote:
Is there a simple way to check for existence of a driver? I could
even check for /dev/sndstat, though that doesn't seem elegant to
me...
kldstat -v, but really /dev/sndstat seems simpler and just as
effective.
Cheers-- I was thinking of a kernel-level function though.
cognet@ suggested using modfind(sound), I'll go with that.
Obvious question is what the panic is. Checking for modules loaded is
papering over some issue.
True, although I figured that it was a simple conflict, possibly to do
with sndstat.
Also, I'm getting panics with the following patch, whether sound is
loaded or not :)
+ if (modfind(sound) = 0)
+ {
+ cmn_err (CE_WARN, A conflicting sound driver is already loaded);
+ return EBUSY;
+ }
+
Is there a better way to handle such conflicts?
You have missed the point. There is some bug in oss driver that causing
the panic. Presumed 'conflict' cannot cause the harm itself, besides not
allowing second driver to attach to the same device, and should not result
in panic. Trying to implement a half-measure that only covers the problem
you do a mis-service.
And you still did not provided the panic message.
I'm sorry, you're right. However, your guess was in fact correct;
make_dev was being called, which returned a null pointer because it
failed.
The patch at [1] stops the panic, however I was hoping that returning
EBUSY would abort loading the module... At the moment it loads the
module, and doesn't create the sndstat dev, which causes weird errors
with the oss binary commands.
Since this solves the panic and anyone should be able to work out from
the warning message what the problem is, AND this is a port that
apparently no-one else uses, should this be sufficient?
BTW, it only affects FreeBSD 9+, couldn't reproduce on my 8.2 dev
machine, but could once I upgraded it.
On 8.2, there is no check in the devfs for duplicated cdev names, AFAIR.
So you get absolutely undeterministic behaviour which driver is referenced
by devfs node.
Chris
[1]
http://www.bayofrum.net/~crees/patches/oss-patch-kernel-OS-FreeBSD-os_freebsd.c
I highly recommend to return error in case of any make_dev_p(9) failure, and
not only EEXIST.
That'd be great-- but I can't work out how to do it :(
Do I need to return a different value?
Chris
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Checking for other kernel modules on load
On Thu, Dec 29, 2011 at 12:53:19PM +, Chris Rees wrote:
2011/12/29 Kostik Belousov kostik...@gmail.com:
On Thu, Dec 29, 2011 at 11:46:57AM +, Chris Rees wrote:
2011/12/28 Kostik Belousov kostik...@gmail.com:
On Wed, Dec 28, 2011 at 02:53:42PM +, Chris Rees wrote:
2011/12/28 Kostik Belousov kostik...@gmail.com:
On Wed, Dec 28, 2011 at 12:23:58PM +, Chris Rees wrote:
On 28 December 2011 12:21, Daniel O'Connor docon...@gsoft.com.au
wrote:
On 28/12/2011, at 22:07, Chris Rees wrote:
Is there a simple way to check for existence of a driver? I could
even check for /dev/sndstat, though that doesn't seem elegant to
me...
kldstat -v, but really /dev/sndstat seems simpler and just as
effective.
Cheers-- I was thinking of a kernel-level function though.
cognet@ suggested using modfind(sound), I'll go with that.
Obvious question is what the panic is. Checking for modules loaded is
papering over some issue.
True, although I figured that it was a simple conflict, possibly to do
with sndstat.
Also, I'm getting panics with the following patch, whether sound is
loaded or not :)
+ if (modfind(sound) = 0)
+ {
+ cmn_err (CE_WARN, A conflicting sound driver is already
loaded);
+ return EBUSY;
+ }
+
Is there a better way to handle such conflicts?
You have missed the point. There is some bug in oss driver that causing
the panic. Presumed 'conflict' cannot cause the harm itself, besides not
allowing second driver to attach to the same device, and should not
result
in panic. Trying to implement a half-measure that only covers the problem
you do a mis-service.
And you still did not provided the panic message.
I'm sorry, you're right. However, your guess was in fact correct;
make_dev was being called, which returned a null pointer because it
failed.
The patch at [1] stops the panic, however I was hoping that returning
EBUSY would abort loading the module... At the moment it loads the
module, and doesn't create the sndstat dev, which causes weird errors
with the oss binary commands.
Since this solves the panic and anyone should be able to work out from
the warning message what the problem is, AND this is a port that
apparently no-one else uses, should this be sufficient?
BTW, it only affects FreeBSD 9+, couldn't reproduce on my 8.2 dev
machine, but could once I upgraded it.
On 8.2, there is no check in the devfs for duplicated cdev names, AFAIR.
So you get absolutely undeterministic behaviour which driver is referenced
by devfs node.
Chris
[1]
http://www.bayofrum.net/~crees/patches/oss-patch-kernel-OS-FreeBSD-os_freebsd.c
I highly recommend to return error in case of any make_dev_p(9) failure, and
not only EEXIST.
That'd be great-- but I can't work out how to do it :(
Do I need to return a different value?
error = make_dev_p();
if (error != 0) {
printf(Error creating device node /dev/%s: %d\n, name, error);
return (error);
}
Or I do not understand your question.
pgpv6Kv0D7MoL.pgp
Description: PGP signature
Re: Checking for other kernel modules on load
2011/12/28 Kostik Belousov kostik...@gmail.com:
On Wed, Dec 28, 2011 at 02:53:42PM +, Chris Rees wrote:
2011/12/28 Kostik Belousov kostik...@gmail.com:
On Wed, Dec 28, 2011 at 12:23:58PM +, Chris Rees wrote:
On 28 December 2011 12:21, Daniel O'Connor docon...@gsoft.com.au wrote:
On 28/12/2011, at 22:07, Chris Rees wrote:
Is there a simple way to check for existence of a driver? I could
even check for /dev/sndstat, though that doesn't seem elegant to me...
kldstat -v, but really /dev/sndstat seems simpler and just as effective.
Cheers-- I was thinking of a kernel-level function though.
cognet@ suggested using modfind(sound), I'll go with that.
Obvious question is what the panic is. Checking for modules loaded is
papering over some issue.
True, although I figured that it was a simple conflict, possibly to do
with sndstat.
Also, I'm getting panics with the following patch, whether sound is
loaded or not :)
+ if (modfind(sound) = 0)
+ {
+ cmn_err (CE_WARN, A conflicting sound driver is already loaded);
+ return EBUSY;
+ }
+
Is there a better way to handle such conflicts?
You have missed the point. There is some bug in oss driver that causing
the panic. Presumed 'conflict' cannot cause the harm itself, besides not
allowing second driver to attach to the same device, and should not result
in panic. Trying to implement a half-measure that only covers the problem
you do a mis-service.
And you still did not provided the panic message.
I'm sorry, you're right. However, your guess was in fact correct;
make_dev was being called, which returned a null pointer because it
failed.
The patch at [1] stops the panic, however I was hoping that returning
EBUSY would abort loading the module... At the moment it loads the
module, and doesn't create the sndstat dev, which causes weird errors
with the oss binary commands.
Since this solves the panic and anyone should be able to work out from
the warning message what the problem is, AND this is a port that
apparently no-one else uses, should this be sufficient?
BTW, it only affects FreeBSD 9+, couldn't reproduce on my 8.2 dev
machine, but could once I upgraded it.
Chris
[1]
http://www.bayofrum.net/~crees/patches/oss-patch-kernel-OS-FreeBSD-os_freebsd.c
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Checking for other kernel modules on load
Hi all, Apologies for the noob question-- I'm trying to stop audio/oss causing panics when loaded on a system that includes DEVICE sound in its kernel config (which has been GENERIC for ~6months now :)) Is there a simple way to check for existence of a driver? I could even check for /dev/sndstat, though that doesn't seem elegant to me... Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Checking for other kernel modules on load
On 28 December 2011 12:21, Daniel O'Connor docon...@gsoft.com.au wrote: On 28/12/2011, at 22:07, Chris Rees wrote: Is there a simple way to check for existence of a driver? I could even check for /dev/sndstat, though that doesn't seem elegant to me... kldstat -v, but really /dev/sndstat seems simpler and just as effective. Cheers-- I was thinking of a kernel-level function though. cognet@ suggested using modfind(sound), I'll go with that. Thanks! Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Checking for other kernel modules on load
On 28/12/2011, at 22:07, Chris Rees wrote: Is there a simple way to check for existence of a driver? I could even check for /dev/sndstat, though that doesn't seem elegant to me... kldstat -v, but really /dev/sndstat seems simpler and just as effective. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Checking for other kernel modules on load
On Wed, Dec 28, 2011 at 12:23:58PM +, Chris Rees wrote: On 28 December 2011 12:21, Daniel O'Connor docon...@gsoft.com.au wrote: On 28/12/2011, at 22:07, Chris Rees wrote: Is there a simple way to check for existence of a driver? I could even check for /dev/sndstat, though that doesn't seem elegant to me... kldstat -v, but really /dev/sndstat seems simpler and just as effective. Cheers-- I was thinking of a kernel-level function though. cognet@ suggested using modfind(sound), I'll go with that. Obvious question is what the panic is. Checking for modules loaded is papering over some issue. pgpnYaFqKXxNx.pgp Description: PGP signature
Re: Checking for other kernel modules on load
2011/12/28 Kostik Belousov kostik...@gmail.com:
On Wed, Dec 28, 2011 at 12:23:58PM +, Chris Rees wrote:
On 28 December 2011 12:21, Daniel O'Connor docon...@gsoft.com.au wrote:
On 28/12/2011, at 22:07, Chris Rees wrote:
Is there a simple way to check for existence of a driver? I could
even check for /dev/sndstat, though that doesn't seem elegant to me...
kldstat -v, but really /dev/sndstat seems simpler and just as effective.
Cheers-- I was thinking of a kernel-level function though.
cognet@ suggested using modfind(sound), I'll go with that.
Obvious question is what the panic is. Checking for modules loaded is
papering over some issue.
True, although I figured that it was a simple conflict, possibly to do
with sndstat.
Also, I'm getting panics with the following patch, whether sound is
loaded or not :)
+ if (modfind(sound) = 0)
+{
+ cmn_err (CE_WARN, A conflicting sound driver is already loaded);
+ return EBUSY;
+}
+
Is there a better way to handle such conflicts?
Chris
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Checking for other kernel modules on load
On Wed, Dec 28, 2011 at 02:53:42PM +, Chris Rees wrote:
2011/12/28 Kostik Belousov kostik...@gmail.com:
On Wed, Dec 28, 2011 at 12:23:58PM +, Chris Rees wrote:
On 28 December 2011 12:21, Daniel O'Connor docon...@gsoft.com.au wrote:
On 28/12/2011, at 22:07, Chris Rees wrote:
Is there a simple way to check for existence of a driver? I could
even check for /dev/sndstat, though that doesn't seem elegant to me...
kldstat -v, but really /dev/sndstat seems simpler and just as effective.
Cheers-- I was thinking of a kernel-level function though.
cognet@ suggested using modfind(sound), I'll go with that.
Obvious question is what the panic is. Checking for modules loaded is
papering over some issue.
True, although I figured that it was a simple conflict, possibly to do
with sndstat.
Also, I'm getting panics with the following patch, whether sound is
loaded or not :)
+ if (modfind(sound) = 0)
+{
+ cmn_err (CE_WARN, A conflicting sound driver is already loaded);
+ return EBUSY;
+}
+
Is there a better way to handle such conflicts?
You have missed the point. There is some bug in oss driver that causing
the panic. Presumed 'conflict' cannot cause the harm itself, besides not
allowing second driver to attach to the same device, and should not result
in panic. Trying to implement a half-measure that only covers the problem
you do a mis-service.
And you still did not provided the panic message.
pgpUT1vbYGa31.pgp
Description: PGP signature
printf doesn't work from kernel modules
Hello Hackers, Recently I installed 8.1 on my laptop and recompiled the kernel. The system works fine, but I have a strange problem with my own trivial kernel module. I noticed that printf function doesn't produce any output (according to dmesg) if I call it from a module. Note, that the same module works perfectly on another 8.1 and CURRENT systems. Moreover, I added debug message (printf (Bla bla bla\n);) in my kernel and found that it works fine (i.e. works if compiled directly in kernel, but doesn't work from module). Same effect with stock 8.1 kernel. I see the same problem with examples in /usr/share/examples/kld. I don't believe this is a real problem in FreeBSD. I'm sure this is some kind of configuration issue, but I cannot understand what exactly is wrong. What could cause such behaviour? Any ideas? Thanks! -- Sincerely yours, Dmitry V. Krivenok e-mail: krivenok.dmi...@gmail.com skype: krivenok_dmitry jabber: krivenok_dmi...@jabber.ru icq: 242-526-443 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: printf doesn't work from kernel modules
On Mon, Nov 22, 2010 at 5:38 AM, Dmitry Krivenok krivenok.dmi...@gmail.com wrote: Hello Hackers, Recently I installed 8.1 on my laptop and recompiled the kernel. The system works fine, but I have a strange problem with my own trivial kernel module. I noticed that printf function doesn't produce any output (according to dmesg) if I call it from a module. Note, that the same module works perfectly on another 8.1 and CURRENT systems. Moreover, I added debug message (printf (Bla bla bla\n);) in my kernel and found that it works fine (i.e. works if compiled directly in kernel, but doesn't work from module). Same effect with stock 8.1 kernel. I see the same problem with examples in /usr/share/examples/kld. I don't believe this is a real problem in FreeBSD. I'm sure this is some kind of configuration issue, but I cannot understand what exactly is wrong. What could cause such behaviour? Any ideas? Which example did you try and run (it looks like the dyn_sysctl test would be a good one to try)? -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: printf doesn't work from kernel modules
Just tried dys_sysctl. It doesn't work as well. Below are the results I got: r...@olimpico-freebsd 22:04:17 /usr/share/examples/kld/dyn_sysctl # [0] uname -a FreeBSD olimpico-freebsd 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Nov 22 21:35:15 MSK 2010 r...@olimpico-freebsd:/usr/obj/usr/src/sys/GENERIC i386 r...@olimpico-freebsd 22:04:20 /usr/share/examples/kld/dyn_sysctl # [0] kldstat Id Refs AddressSize Name 11 0xc040 bb5504 kernel r...@olimpico-freebsd 22:04:24 /usr/share/examples/kld/dyn_sysctl # [0] dmesg | tail -n 3 ums0: 3 buttons and [XYZ] coordinates ID=0 ugen2.2: Broadcom Corp at usbus2 em0: link state changed to UP r...@olimpico-freebsd 22:04:39 /usr/share/examples/kld/dyn_sysctl # [0 0] make load /sbin/kldload -v /usr/share/examples/kld/dyn_sysctl/dyn_sysctl.ko Loaded /usr/share/examples/kld/dyn_sysctl/dyn_sysctl.ko, id=2 r...@olimpico-freebsd 22:04:49 /usr/share/examples/kld/dyn_sysctl # [0] kldstat Id Refs AddressSize Name 12 0xc040 bb5504 kernel 21 0xc855d000 3000 dyn_sysctl.ko r...@olimpico-freebsd 22:04:53 /usr/share/examples/kld/dyn_sysctl # [0] dmesg | tail -n 3 ums0: 3 buttons and [XYZ] coordinates ID=0 ugen2.2: Broadcom Corp at usbus2 em0: link state changed to UP r...@olimpico-freebsd 22:04:57 /usr/share/examples/kld/dyn_sysctl # [0 0] make unload /sbin/kldunload -v dyn_sysctl.ko Unloading dyn_sysctl.ko, id=2 r...@olimpico-freebsd 22:05:04 /usr/share/examples/kld/dyn_sysctl # [0] kldstat Id Refs AddressSize Name 11 0xc040 bb5504 kernel r...@olimpico-freebsd 22:05:07 /usr/share/examples/kld/dyn_sysctl # [0] dmesg | tail -n 3 ums0: 3 buttons and [XYZ] coordinates ID=0 ugen2.2: Broadcom Corp at usbus2 em0: link state changed to UP r...@olimpico-freebsd 22:05:09 /usr/share/examples/kld/dyn_sysctl # [0 0] Please note that I run standard example on default 8.1 kernel (GENERIC). Dmitry Which example did you try and run (it looks like the dyn_sysctl test would be a good one to try)? -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: kernel modules into static kernel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2010/07/19 20:50, Tim Judd wrote: Hellos, Of interest, I can get GEOM_UZIP kernel module as part of the kernel, but the GEOM_UZIP kernel module has a dependency on ZLIB. If I build a kernel with GEOM_UZIP, will the relavant ZLIB pieces also be in the kernel? Yes. Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBCAAGBQJMRd0KAAoJEATO+BI/yjfB9EEH/38i8b0LdphAnpKEmKO0u1eU tCqM0LiSd8iJM3ZxilBvrIVofDXEqQW6PoDZ3m3KTRu39muZRqhRB1aVt3vbTCev xhDFEAgVrC0G16/JI9OE3h4Qtg0WT85Oyt/pZOTpzlaSXySByYyLHL2WbcC2FAMg t1R3ej35jqdmo2heSq3TnuRHQ6ykeqWqtHN18SMFrs+ywC6FYvgpR7rA2gsSa194 tiHEleR0IiBeklksHX38GPwWytYhgVwOAEdy+6JlFqcHAulFON47jjhq/9YAa6sq xAYBoJStnIVqIf4pjvzMzUrn07DUVbs9P4xbgJkTU0NXuuFvyaiH0VgzuU/zHt8= =Q7Yq -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: kernel modules into static kernel
On Monday, July 19, 2010 11:50:37 pm Tim Judd wrote: Hellos, Of interest, I can get GEOM_UZIP kernel module as part of the kernel, but the GEOM_UZIP kernel module has a dependency on ZLIB. If I build a kernel with GEOM_UZIP, will the relavant ZLIB pieces also be in the kernel? Yes. GEOM_UZIP sucks in net/zlib.c (look at sys/conf/files and search for 'uzip' to see what GEOM_UZIP includes in the build). -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: kernel modules into static kernel
On 7/20/10, John Baldwin j...@freebsd.org wrote: On Monday, July 19, 2010 11:50:37 pm Tim Judd wrote: Hellos, Of interest, I can get GEOM_UZIP kernel module as part of the kernel, but the GEOM_UZIP kernel module has a dependency on ZLIB. If I build a kernel with GEOM_UZIP, will the relavant ZLIB pieces also be in the kernel? Yes. GEOM_UZIP sucks in net/zlib.c (look at sys/conf/files and search for 'uzip' to see what GEOM_UZIP includes in the build). -- John Baldwin Extremely appreciated. Thanks John ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
kernel modules into static kernel
Hellos, Of interest, I can get GEOM_UZIP kernel module as part of the kernel, but the GEOM_UZIP kernel module has a dependency on ZLIB. If I build a kernel with GEOM_UZIP, will the relavant ZLIB pieces also be in the kernel? I love to torture myself by putting BSD in environments it's not normally in, and this round is trying to get a (UNDOCUMENTED?) GEOM_UZIP root filesystem Thanks for any pointers, --Tim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)]
Gary Jennejohn gljennj...@googlemail.com wrote: IMO if you're going to make the binaries in base non-executable you might just as well delete them. The chmod is reversible without having to recover the base binaries from somewhere. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: amd64 kernel modules: mapping sections to addresses
On 25 Jun 2010, at 10:28, Andriy Gapon wrote: Here's a patch that is supposed to do the right thing for dtrace. Perhaps I should have put the new code under __amd64__, but I decided to go more generic and check for module's ELF type (ET_REL). Reviews and testing are welcome! I believe this is good to go. Regards, -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)]
On Thu, 24 Jun 2010 09:54:45 -0700 Ted Faber fa...@isi.edu wrote: On Thu, Jun 24, 2010 at 08:29:57AM -0700, Ted Faber wrote: On Thu, Jun 24, 2010 at 09:40:00AM +0100, Tom Evans wrote: I also have this in make.conf: CUPS_OVERWRITE_BASE=yes WITHOUT_LPR=yes which print/cups-base uses to do make any lpr related binaries in /usr/bin non-executable, so they are skipped over and the cups specific ones in /usr/loca/bin are used instead. WITHOUT_LPR just stops LPR being built by buildworld. The clear winner, and one I was unaware of. Thanks, Tom. CUPS_OVERWRITE_BASE seems to do an odd thing. It doesn't install the cups binaries in /usr/bin, but it does do a chmod on everything it replaces in /usr/bin . For example praxis:~$ ls -l /usr/bin/lpr -r-sr-sr-x 1 root daemon 29876 Jun 24 09:16 /usr/bin/lpr # portupgrade -f cups-base-1.4.3 praxis:~$ ls -l /usr/bin/lpr -- 1 root daemon 29876 Jun 24 09:16 /usr/bin/lpr I'll still use it, but interesting behavior. IMO if you're going to make the binaries in base non-executable you might just as well delete them. But CUPS_OVERWRITE_BASE does have the advantage that it works without (active) user intervention. -- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: amd64 kernel modules: mapping sections to addresses
Here's a patch that is supposed to do the right thing for dtrace.
Perhaps I should have put the new code under __amd64__, but I decided to go more
generic and check for module's ELF type (ET_REL).
Reviews and testing are welcome!
diff --git a/cddl/contrib/opensolaris/lib/libdtrace/common/dt_impl.h
b/cddl/contrib/opensolaris/lib/libdtrace/common/dt_impl.h
index 6bcc5bc..a712d24 100644
--- a/cddl/contrib/opensolaris/lib/libdtrace/common/dt_impl.h
+++ b/cddl/contrib/opensolaris/lib/libdtrace/common/dt_impl.h
@@ -137,6 +137,7 @@ typedef struct dt_module {
dt_idhash_t *dm_extern; /* external symbol definitions */
#if !defined(sun)
caddr_t dm_reloc_offset;/* Symbol relocation offset. */
+ uintptr_t *dm_sec_offsets;
#endif
} dt_module_t;
diff --git a/cddl/contrib/opensolaris/lib/libdtrace/common/dt_module.c
b/cddl/contrib/opensolaris/lib/libdtrace/common/dt_module.c
index af17501..d33fb95 100644
--- a/cddl/contrib/opensolaris/lib/libdtrace/common/dt_module.c
+++ b/cddl/contrib/opensolaris/lib/libdtrace/common/dt_module.c
@@ -83,6 +83,14 @@ dt_module_syminit32(dt_module_t *dmp)
uint_t i, n = dmp-dm_nsymelems;
uint_t asrsv = 0;
+#if defined(__FreeBSD__)
+ GElf_Ehdr ehdr;
+ int is_elf_obj;
+
+ gelf_getehdr(dmp-dm_elf, ehdr);
+ is_elf_obj = (ehdr.e_type == ET_REL);
+#endif
+
for (i = 0; i n; i++, sym++) {
const char *name = base + sym-st_name;
uchar_t type = ELF32_ST_TYPE(sym-st_info);
@@ -97,8 +105,12 @@ dt_module_syminit32(dt_module_t *dmp)
(ELF32_ST_BIND(sym-st_info) != STB_LOCAL || sym-st_size))
{
asrsv++; /* reserve space in the address map */
-#if !defined(sun)
+#if defined(__FreeBSD__)
sym-st_value += (Elf_Addr) dmp-dm_reloc_offset;
+ if (is_elf_obj sym-st_shndx != SHN_UNDEF
+ sym-st_shndx ehdr.e_shnum)
+ sym-st_value +=
+ dmp-dm_sec_offsets[sym-st_shndx];
#endif
}
@@ -117,6 +129,14 @@ dt_module_syminit64(dt_module_t *dmp)
uint_t i, n = dmp-dm_nsymelems;
uint_t asrsv = 0;
+#if defined(__FreeBSD__)
+ GElf_Ehdr ehdr;
+ int is_elf_obj;
+
+ gelf_getehdr(dmp-dm_elf, ehdr);
+ is_elf_obj = (ehdr.e_type == ET_REL);
+#endif
+
for (i = 0; i n; i++, sym++) {
const char *name = base + sym-st_name;
uchar_t type = ELF64_ST_TYPE(sym-st_info);
@@ -130,9 +150,12 @@ dt_module_syminit64(dt_module_t *dmp)
if (sym-st_value != 0
(ELF64_ST_BIND(sym-st_info) != STB_LOCAL || sym-st_size))
{
asrsv++; /* reserve space in the address map */
-
-#if !defined(sun)
+#if defined(__FreeBSD__)
sym-st_value += (Elf_Addr) dmp-dm_reloc_offset;
+ if (is_elf_obj sym-st_shndx != SHN_UNDEF
+ sym-st_shndx ehdr.e_shnum)
+ sym-st_value +=
+ dmp-dm_sec_offsets[sym-st_shndx];
#endif
}
@@ -722,7 +745,12 @@ dt_module_unload(dtrace_hdl_t *dtp, dt_module_t *dmp)
free(dmp-dm_asmap);
dmp-dm_asmap = NULL;
}
-
+#if defined(__FreeBSD__)
+ if (dmp-dm_sec_offsets != NULL) {
+ free(dmp-dm_sec_offsets);
+ dmp-dm_sec_offsets = NULL;
+ }
+#endif
dmp-dm_symfree = 0;
dmp-dm_nsymbuckets = 0;
dmp-dm_nsymelems = 0;
@@ -846,9 +874,12 @@ dt_module_update(dtrace_hdl_t *dtp, struct kld_file_stat
*k_stat)
(void) snprintf(fname, sizeof (fname),
%s/%s/object, OBJFS_ROOT, name);
#else
+ GElf_Ehdr ehdr;
GElf_Phdr ph;
char name[MAXPATHLEN];
+ uintptr_t mapbase, alignmask;
int i = 0;
+ int is_elf_obj;
(void) strlcpy(name, k_stat-name, sizeof(name));
(void) strlcpy(fname, k_stat-pathname, sizeof(fname));
@@ -893,7 +924,20 @@ dt_module_update(dtrace_hdl_t *dtp, struct kld_file_stat
*k_stat)
dt_module_destroy(dtp, dmp);
return;
}
-
+#if defined(__FreeBSD__)
+ mapbase = (uintptr_t)k_stat-address;
+ gelf_getehdr(dmp-dm_elf, ehdr);
+ is_elf_obj = (ehdr.e_type == ET_REL);
+ if (is_elf_obj) {
+ dmp-dm_sec_offsets =
+ malloc(ehdr.e_shnum * sizeof(*dmp-dm_sec_offsets));
+ if (dmp-dm_sec_offsets == NULL) {
+ dt_dprintf(failed to allocate memory\n);
+ dt_module_destroy(dtp, dmp);
+ return;
+ }
+ }
+#endif
/*
* Iterate over the section headers locating various sections of
* interest and use their attributes to flesh out the dt_module_t.
@@ -902,7 +946,19 @@ dt_module_update(dtrace_hdl_t
using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)]
On Wed, 23 Jun 2010 18:15:09 -0700 Ted Faber fa...@isi.edu wrote: (/usr/local/bin/ preceeds /usr/bin in my path so I can use the lpr commands from cupsd, though it's evidently a bit of a dangerous idea.) [trimmed Cc] I use cupsd and have these settings to get around using the base system lp stuff: in /etc/src.conf - WITHOUT_LPR=yes and these symbolic links in /usr/bin lrwxr-xr-x 1 root wheel 17 Mar 18 2009 /usr/bin/lp - /usr/local/bin/lp lrwxr-xr-x 1 root wheel 24 Mar 18 2009 /usr/bin/lpoptions - /usr/local/bin/lpoptions lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpq - /usr/local/bin/lpq lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpr - /usr/local/bin/lpr lrwxr-xr-x 1 root wheel 19 Mar 18 2009 /usr/bin/lprm - /usr/local/bin/lprm lrwxr-xr-x 1 root wheel 21 Mar 18 2009 /usr/bin/lpstat - /usr/local/bin/lpstat and /usr/bin is _before_ /usr/local/bin in my PATH. --- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)]
On Thu, 24 Jun 2010 10:30:26 +0200 Alban Hertroys dal...@solfertje.student.utwente.nl wrote: On 24 Jun 2010, at 9:23, Gary Jennejohn wrote: On Wed, 23 Jun 2010 18:15:09 -0700 Ted Faber fa...@isi.edu wrote: (/usr/local/bin/ preceeds /usr/bin in my path so I can use the lpr commands from cupsd, though it's evidently a bit of a dangerous idea.) [trimmed Cc] I use cupsd and have these settings to get around using the base system lp stuff: in /etc/src.conf - WITHOUT_LPR=yes and these symbolic links in /usr/bin lrwxr-xr-x 1 root wheel 17 Mar 18 2009 /usr/bin/lp - /usr/local/bin/lp lrwxr-xr-x 1 root wheel 24 Mar 18 2009 /usr/bin/lpoptions - /usr/local/bin/lpoptions lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpq - /usr/local/bin/lpq lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpr - /usr/local/bin/lpr lrwxr-xr-x 1 root wheel 19 Mar 18 2009 /usr/bin/lprm - /usr/local/bin/lprm lrwxr-xr-x 1 root wheel 21 Mar 18 2009 /usr/bin/lpstat - /usr/local/bin/lpstat and /usr/bin is _before_ /usr/local/bin in my PATH. Wouldn't it be easier to alias those commands instead of physically replacing them? In my .tcshrc I have: alias lp/usr/local/bin/lp alias lpq /usr/local/bin/lpq alias lpr /usr/local/bin/lpr alias lprm /usr/local/bin/lprm I only have /usr/local/bin/lpoptions on my system (7-STABLE), so I guess that's exclusive to CUPS, hence no need for me to alias it. That's a valid option, of course. My thought was that the base lp isn't being installed anyway so it's just as simple to use symbolic links. -- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)]
On Thu, Jun 24, 2010 at 8:23 AM, Gary Jennejohn gljennj...@googlemail.com wrote: On Wed, 23 Jun 2010 18:15:09 -0700 Ted Faber fa...@isi.edu wrote: (/usr/local/bin/ preceeds /usr/bin in my path so I can use the lpr commands from cupsd, though it's evidently a bit of a dangerous idea.) [trimmed Cc] I use cupsd and have these settings to get around using the base system lp stuff: in /etc/src.conf - WITHOUT_LPR=yes and these symbolic links in /usr/bin lrwxr-xr-x 1 root wheel 17 Mar 18 2009 /usr/bin/lp - /usr/local/bin/lp lrwxr-xr-x 1 root wheel 24 Mar 18 2009 /usr/bin/lpoptions - /usr/local/bin/lpoptions lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpq - /usr/local/bin/lpq lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpr - /usr/local/bin/lpr lrwxr-xr-x 1 root wheel 19 Mar 18 2009 /usr/bin/lprm - /usr/local/bin/lprm lrwxr-xr-x 1 root wheel 21 Mar 18 2009 /usr/bin/lpstat - /usr/local/bin/lpstat and /usr/bin is _before_ /usr/local/bin in my PATH. --- Gary Jennejohn I also have this in make.conf: CUPS_OVERWRITE_BASE=yes WITHOUT_LPR=yes which print/cups-base uses to do make any lpr related binaries in /usr/bin non-executable, so they are skipped over and the cups specific ones in /usr/loca/bin are used instead. WITHOUT_LPR just stops LPR being built by buildworld. Cheers Tom ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1
Andriy Gapon a...@icyb.net.ua writes: Yes, you are absolutely correct. This comes from the fact that amd64 uses simple objects files (aka .o) as kernel modules and i386 uses full-blow dso. The obvious question is: since, as I understand, amd64's solution is superior, what would it take to switch to .o on other platforms? DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)]
On Thu, Jun 24, 2010 at 10:21 AM, Andrew Reilly arei...@bigpond.net.au wrote: On Thu, Jun 24, 2010 at 09:23:37AM +0200, Gary Jennejohn wrote: in /etc/src.conf - WITHOUT_LPR=yes and these symbolic links in /usr/bin lrwxr-xr-x 1 root wheel 17 Mar 18 2009 /usr/bin/lp - /usr/local/bin/lp lrwxr-xr-x 1 root wheel 24 Mar 18 2009 /usr/bin/lpoptions - /usr/local/bin/lpoptions lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpq - /usr/local/bin/lpq lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpr - /usr/local/bin/lpr lrwxr-xr-x 1 root wheel 19 Mar 18 2009 /usr/bin/lprm - /usr/local/bin/lprm lrwxr-xr-x 1 root wheel 21 Mar 18 2009 /usr/bin/lpstat - /usr/local/bin/lpstat and /usr/bin is _before_ /usr/local/bin in my PATH. Since you have /usr/local/bin in your path, why bother with the symlinks at all? Your shell will find them in their new locations just fine. You'll want to remove the old ones from /usr/bin, but make delete-old will probably do that nicely anyway. Cheers, -- Andrew make delete-old removes old deprecated files, not files that weren't built because of src.conf options. It definitely will not remove the lpr binaries from /usr/bin if they exist there. There already is a proper solution for this: if you want to have LPR from CUPS, and don't want to use LPR from base, then you set these settings in make.conf: CUPS_OVERWRITE_BASE=yes WITHOUT_LPR=yes With these, lpr in base will not be built, and print/cups-base will deactivate any base system lpr binaries that are installed. It's documented in the FreeBSD CUPS article here: http://www.freebsd.org/doc/en/articles/cups/article.html#PRINTING-CUPS-PORTS-KNOBS Cheers Tom ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)]
Tom Evans ha scritto: make delete-old removes old deprecated files, not files that weren't built because of src.conf options. I think you are wrong: http://www.freebsd.org/cgi/cvsweb.cgi/src/tools/build/mk/OptionalObsoleteFiles.inc?rev=1.66 -- Alex Dupre ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)]
On Thu, Jun 24, 2010 at 10:45 AM, Alex Dupre a...@freebsd.org wrote: Tom Evans ha scritto: make delete-old removes old deprecated files, not files that weren't built because of src.conf options. I think you are wrong: http://www.freebsd.org/cgi/cvsweb.cgi/src/tools/build/mk/OptionalObsoleteFiles.inc?rev=1.66 -- Alex Dupre Meh, OK. It didn't used to, there was a discussion about this about 6 months ago, and yes, check the history of that file. This support was added in February, nothing in /usr/src/UPDATING about it.. Still, besides the point. There is one supported way to get cups-base lpr used instead of base lpr, and it's got not much to do with 'make delete-old'. http://www.freebsd.org/doc/en/articles/cups/article.html#PRINTING-CUPS-PORTS-KNOBS Cheers Tom ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)]
On 24 Jun 2010, at 9:23, Gary Jennejohn wrote: On Wed, 23 Jun 2010 18:15:09 -0700 Ted Faber fa...@isi.edu wrote: (/usr/local/bin/ preceeds /usr/bin in my path so I can use the lpr commands from cupsd, though it's evidently a bit of a dangerous idea.) [trimmed Cc] I use cupsd and have these settings to get around using the base system lp stuff: in /etc/src.conf - WITHOUT_LPR=yes and these symbolic links in /usr/bin lrwxr-xr-x 1 root wheel 17 Mar 18 2009 /usr/bin/lp - /usr/local/bin/lp lrwxr-xr-x 1 root wheel 24 Mar 18 2009 /usr/bin/lpoptions - /usr/local/bin/lpoptions lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpq - /usr/local/bin/lpq lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpr - /usr/local/bin/lpr lrwxr-xr-x 1 root wheel 19 Mar 18 2009 /usr/bin/lprm - /usr/local/bin/lprm lrwxr-xr-x 1 root wheel 21 Mar 18 2009 /usr/bin/lpstat - /usr/local/bin/lpstat and /usr/bin is _before_ /usr/local/bin in my PATH. Wouldn't it be easier to alias those commands instead of physically replacing them? In my .tcshrc I have: alias lp/usr/local/bin/lp alias lpq /usr/local/bin/lpq alias lpr /usr/local/bin/lpr alias lprm /usr/local/bin/lprm I only have /usr/local/bin/lpoptions on my system (7-STABLE), so I guess that's exclusive to CUPS, hence no need for me to alias it. Alban Hertroys -- Screwing up is an excellent way to attach something to the ceiling. !DSPAM:,4c2317b8286214077543485! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)]
On Thu, Jun 24, 2010 at 09:23:37AM +0200, Gary Jennejohn wrote: in /etc/src.conf - WITHOUT_LPR=yes and these symbolic links in /usr/bin lrwxr-xr-x 1 root wheel 17 Mar 18 2009 /usr/bin/lp - /usr/local/bin/lp lrwxr-xr-x 1 root wheel 24 Mar 18 2009 /usr/bin/lpoptions - /usr/local/bin/lpoptions lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpq - /usr/local/bin/lpq lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpr - /usr/local/bin/lpr lrwxr-xr-x 1 root wheel 19 Mar 18 2009 /usr/bin/lprm - /usr/local/bin/lprm lrwxr-xr-x 1 root wheel 21 Mar 18 2009 /usr/bin/lpstat - /usr/local/bin/lpstat and /usr/bin is _before_ /usr/local/bin in my PATH. Since you have /usr/local/bin in your path, why bother with the symlinks at all? Your shell will find them in their new locations just fine. You'll want to remove the old ones from /usr/bin, but make delete-old will probably do that nicely anyway. Cheers, -- Andrew ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)]
* Andrew Reilly arei...@bigpond.net.au wrote: On Thu, Jun 24, 2010 at 09:23:37AM +0200, Gary Jennejohn wrote: in /etc/src.conf - WITHOUT_LPR=yes and these symbolic links in /usr/bin lrwxr-xr-x 1 root wheel 17 Mar 18 2009 /usr/bin/lp - /usr/local/bin/lp lrwxr-xr-x 1 root wheel 24 Mar 18 2009 /usr/bin/lpoptions - /usr/local/bin/lpoptions lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpq - /usr/local/bin/lpq lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpr - /usr/local/bin/lpr lrwxr-xr-x 1 root wheel 19 Mar 18 2009 /usr/bin/lprm - /usr/local/bin/lprm lrwxr-xr-x 1 root wheel 21 Mar 18 2009 /usr/bin/lpstat - /usr/local/bin/lpstat and /usr/bin is _before_ /usr/local/bin in my PATH. Since you have /usr/local/bin in your path, why bother with the symlinks at all? Your shell will find them in their new locations just fine. You'll want to remove the old ones from /usr/bin, but make delete-old will probably do that nicely anyway. In theory, yes. In practice, no. Just for fun, remove your /usr/sbin/sendmail while having Postfix's /usr/local/sbin/sendmail installed. It simply won't work. If I remember correctly, you won't even receive the periodic(8) emails. Nowadays it's probably better, but I remember in the old days GNOME would always print through /usr/bin/lpr, even when CUPS is installed. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpNgoKSxOgsT.pgp Description: PGP signature
Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)]
* Mike Meyer m...@mired.org wrote: Maybe it's time for /usr/sbin/lpwrapper, to do the same thing for print systems? In my opinion, we should just rename mailwrapper to whateverwrapper and list the lpr programs in there as well. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpn1LzLEWm9v.pgp Description: PGP signature
Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)]
On Thu, Jun 24, 2010 at 09:40:00AM +0100, Tom Evans wrote: I also have this in make.conf: CUPS_OVERWRITE_BASE=yes WITHOUT_LPR=yes which print/cups-base uses to do make any lpr related binaries in /usr/bin non-executable, so they are skipped over and the cups specific ones in /usr/loca/bin are used instead. WITHOUT_LPR just stops LPR being built by buildworld. The clear winner, and one I was unaware of. Thanks, Tom. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgpBnQb7UNzNh.pgp Description: PGP signature
Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)]
On Thu, Jun 24, 2010 at 08:29:57AM -0700, Ted Faber wrote: On Thu, Jun 24, 2010 at 09:40:00AM +0100, Tom Evans wrote: I also have this in make.conf: CUPS_OVERWRITE_BASE=yes WITHOUT_LPR=yes which print/cups-base uses to do make any lpr related binaries in /usr/bin non-executable, so they are skipped over and the cups specific ones in /usr/loca/bin are used instead. WITHOUT_LPR just stops LPR being built by buildworld. The clear winner, and one I was unaware of. Thanks, Tom. CUPS_OVERWRITE_BASE seems to do an odd thing. It doesn't install the cups binaries in /usr/bin, but it does do a chmod on everything it replaces in /usr/bin . For example praxis:~$ ls -l /usr/bin/lpr -r-sr-sr-x 1 root daemon 29876 Jun 24 09:16 /usr/bin/lpr # portupgrade -f cups-base-1.4.3 praxis:~$ ls -l /usr/bin/lpr -- 1 root daemon 29876 Jun 24 09:16 /usr/bin/lpr I'll still use it, but interesting behavior. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgpJ2UHzloYfq.pgp Description: PGP signature
Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1
on 23/06/2010 03:38 Hans Petter Selasky said the following: Hi, I'm creating a new thread on this issue. On Tue, Jun 22, 2010 at 04:39:17PM -0400, Ryan Stone wrote: I saw similar behaviour a couple of years ago when I switched from using gcc 4.0.2 to gcc 4.3.0 to compile some out-of-tree KLD modules. The problem ended up being a change in the linker script used by GNU ld for linking kernel modules. It used to always put some magic symbols used by the linker to implement things like sysinits into the module. It was changed to only provide those symbols, which apparently means that the linker would discard those symbols if nothing referenced them(and nothing did reference them). I had to work around it by adding the following to my link line: -u __start_set_sysinit_set -u __start_set_sysuninit_set \ -u __start_set_sysctl_set -u __start_set_modmetadata_set \ -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ -u __stop_set_sysctl_set -u __stop_set_modmetadata_set It appears many kmods are broken because the linker is stripping away static data declared with the section attribute in FreeBSD 8.1-RC1. cite I added those lines to the LDFLAGS in Makefile.kmod in the cuse4bsd port made the module and the result loads and creates the /dev/cuse file. Here's a diff relative to /usr/ports/multimedia/cuse4bsd-kmod/work/cuse4bsd-kmod-0.1.11 just so it's clear what I did. --- Makefile.kmod.orig 2010-02-11 03:28:02.0 -0800 +++ Makefile.kmod 2010-06-22 14:02:52.0 -0700 @@ -30,4 +30,10 @@ KMOD= cuse4bsd SRCS= cuse4bsd_kmod.c device_if.h bus_if.h vnode_if.h +LDFLAGS += -u __start_set_sysinit_set -u __start_set_sysuninit_set \ + -u __start_set_sysctl_set -u __start_set_modmetadata_set \ + -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ + -u __stop_set_sysctl_set -u __stop_set_modmetadata_set + + .include bsd.kmod.mk Running nm -o on the two modules, the difference seems to be that the -u results in some additional absolute symbols being defined: Bad module: $ nm -o /boot/modules/cuse4bsd.ko| grep sys /boot/modules/cuse4bsd.ko:275c r __set_sysinit_set_sym_cuse_kern_init_sys_init /boot/modules/cuse4bsd.ko:2758 r __set_sysuninit_set_sym_cuse_kern_uninit_sys_uninit /boot/modules/cuse4bsd.ko:3194 d cuse_kern_init_sys_init /boot/modules/cuse4bsd.ko:3184 d cuse_kern_uninit_sys_uninit I am not sure if this analysis is correct. I tested on head and stable/8 and my nm output is exactly like above (bad module), still the module loads fine and creates /dev/cuse. I don't think there were any recent changes related to build infrastructure or linker in 8.1. Please consider other possibilities. Good module: $ nm -o ./cuse4bsd.ko | grep sys ./cuse4bsd.ko:28cc r __set_sysinit_set_sym_cuse_kern_init_sys_init ./cuse4bsd.ko:28c8 r __set_sysuninit_set_sym_cuse_kern_uninit_sys_uninit ./cuse4bsd.ko: U __start_set_sysctl_set ./cuse4bsd.ko:28cc A __start_set_sysinit_set ./cuse4bsd.ko:28c8 A __start_set_sysuninit_set ./cuse4bsd.ko: U __stop_set_sysctl_set ./cuse4bsd.ko:28d0 A __stop_set_sysinit_set ./cuse4bsd.ko:28cc A __stop_set_sysuninit_set ./cuse4bsd.ko:3194 d cuse_kern_init_sys_init ./cuse4bsd.ko:3184 d cuse_kern_uninit_sys_uninit /cite -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1
On Wednesday 23 June 2010 08:47:52 Andriy Gapon wrote: on 23/06/2010 03:38 Hans Petter Selasky said the following: Hi, I'm creating a new thread on this issue. On Tue, Jun 22, 2010 at 04:39:17PM -0400, Ryan Stone wrote: I saw similar behaviour a couple of years ago when I switched from using gcc 4.0.2 to gcc 4.3.0 to compile some out-of-tree KLD modules. The problem ended up being a change in the linker script used by GNU ld for linking kernel modules. It used to always put some magic symbols used by the linker to implement things like sysinits into the module. It was changed to only provide those symbols, which apparently means that the linker would discard those symbols if nothing referenced them(and nothing did reference them). I had to work around it by adding the following to my link line: -u __start_set_sysinit_set -u __start_set_sysuninit_set \ -u __start_set_sysctl_set -u __start_set_modmetadata_set \ -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ -u __stop_set_sysctl_set -u __stop_set_modmetadata_set It appears many kmods are broken because the linker is stripping away static data declared with the section attribute in FreeBSD 8.1-RC1. cite I added those lines to the LDFLAGS in Makefile.kmod in the cuse4bsd port made the module and the result loads and creates the /dev/cuse file. Here's a diff relative to /usr/ports/multimedia/cuse4bsd-kmod/work/cuse4bsd-kmod-0.1.11 just so it's clear what I did. --- Makefile.kmod.orig 2010-02-11 03:28:02.0 -0800 +++ Makefile.kmod 2010-06-22 14:02:52.0 -0700 @@ -30,4 +30,10 @@ KMOD= cuse4bsd SRCS= cuse4bsd_kmod.c device_if.h bus_if.h vnode_if.h +LDFLAGS += -u __start_set_sysinit_set -u __start_set_sysuninit_set \ + -u __start_set_sysctl_set -u __start_set_modmetadata_set \ + -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ + -u __stop_set_sysctl_set -u __stop_set_modmetadata_set + + .include bsd.kmod.mk Running nm -o on the two modules, the difference seems to be that the -u results in some additional absolute symbols being defined: Bad module: $ nm -o /boot/modules/cuse4bsd.ko| grep sys /boot/modules/cuse4bsd.ko:275c r __set_sysinit_set_sym_cuse_kern_init_sys_init /boot/modules/cuse4bsd.ko:2758 r __set_sysuninit_set_sym_cuse_kern_uninit_sys_uninit /boot/modules/cuse4bsd.ko:3194 d cuse_kern_init_sys_init /boot/modules/cuse4bsd.ko:3184 d cuse_kern_uninit_sys_uninit I am not sure if this analysis is correct. I tested on head and stable/8 and my nm output is exactly like above (bad module), still the module loads fine and creates /dev/cuse. I don't think there were any recent changes related to build infrastructure or linker in 8.1. Please consider other possibilities. I installed PC-BSD 8.1-RC1 and the stock cuse4bsd module is broken. Andriy, make sure that you re-make the toolchain before building the module in question. Also I think you have to: cd /usr/src ; make buildenv TARGET_ARCH=xxx_target Then you cd to the module directory and type make. --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1
on 23/06/2010 09:52 Hans Petter Selasky said the following: On Wednesday 23 June 2010 08:47:52 Andriy Gapon wrote: on 23/06/2010 03:38 Hans Petter Selasky said the following: Hi, I'm creating a new thread on this issue. On Tue, Jun 22, 2010 at 04:39:17PM -0400, Ryan Stone wrote: I saw similar behaviour a couple of years ago when I switched from using gcc 4.0.2 to gcc 4.3.0 to compile some out-of-tree KLD modules. The problem ended up being a change in the linker script used by GNU ld for linking kernel modules. It used to always put some magic symbols used by the linker to implement things like sysinits into the module. It was changed to only provide those symbols, which apparently means that the linker would discard those symbols if nothing referenced them(and nothing did reference them). I had to work around it by adding the following to my link line: -u __start_set_sysinit_set -u __start_set_sysuninit_set \ -u __start_set_sysctl_set -u __start_set_modmetadata_set \ -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ -u __stop_set_sysctl_set -u __stop_set_modmetadata_set It appears many kmods are broken because the linker is stripping away static data declared with the section attribute in FreeBSD 8.1-RC1. cite I added those lines to the LDFLAGS in Makefile.kmod in the cuse4bsd port made the module and the result loads and creates the /dev/cuse file. Here's a diff relative to /usr/ports/multimedia/cuse4bsd-kmod/work/cuse4bsd-kmod-0.1.11 just so it's clear what I did. --- Makefile.kmod.orig 2010-02-11 03:28:02.0 -0800 +++ Makefile.kmod 2010-06-22 14:02:52.0 -0700 @@ -30,4 +30,10 @@ KMOD= cuse4bsd SRCS= cuse4bsd_kmod.c device_if.h bus_if.h vnode_if.h +LDFLAGS += -u __start_set_sysinit_set -u __start_set_sysuninit_set \ + -u __start_set_sysctl_set -u __start_set_modmetadata_set \ + -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ + -u __stop_set_sysctl_set -u __stop_set_modmetadata_set + + .include bsd.kmod.mk Running nm -o on the two modules, the difference seems to be that the -u results in some additional absolute symbols being defined: Bad module: $ nm -o /boot/modules/cuse4bsd.ko| grep sys /boot/modules/cuse4bsd.ko:275c r __set_sysinit_set_sym_cuse_kern_init_sys_init /boot/modules/cuse4bsd.ko:2758 r __set_sysuninit_set_sym_cuse_kern_uninit_sys_uninit /boot/modules/cuse4bsd.ko:3194 d cuse_kern_init_sys_init /boot/modules/cuse4bsd.ko:3184 d cuse_kern_uninit_sys_uninit I am not sure if this analysis is correct. I tested on head and stable/8 and my nm output is exactly like above (bad module), still the module loads fine and creates /dev/cuse. I don't think there were any recent changes related to build infrastructure or linker in 8.1. Please consider other possibilities. I installed PC-BSD 8.1-RC1 and the stock cuse4bsd module is broken. I don't dispute that it is found broken in particular environments, I just think that the analysis could be incorrect. Andriy, make sure that you re-make the toolchain before building the module in question. Also I think you have to: cd /usr/src ; make buildenv TARGET_ARCH=xxx_target Then you cd to the module directory and type make. I don't think that this is needed when _not_ cross-building for a different architecture. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1
on 23/06/2010 10:02 Andriy Gapon said the following: I don't dispute that it is found broken in particular environments, I just think that the analysis could be incorrect. Which also brings the question - what arch(s) is affected? I tested on amd64. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1
On Wednesday 23 June 2010 09:10:59 Andriy Gapon wrote: on 23/06/2010 10:02 Andriy Gapon said the following: I don't dispute that it is found broken in particular environments, I just think that the analysis could be incorrect. Ok. Which also brings the question - what arch(s) is affected? I tested on amd64. I tested on i386. --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1
On Wed, Jun 23, 2010 at 10:10:59AM +0300, Andriy Gapon wrote: on 23/06/2010 10:02 Andriy Gapon said the following: I don't dispute that it is found broken in particular environments, I just think that the analysis could be incorrect. Which also brings the question - what arch(s) is affected? I tested on amd64. Right. I'm i386 and I have the problem. Good point! -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgpktkci5Z5pk.pgp Description: PGP signature
Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1
On Wed, Jun 23, 2010 at 3:10 AM, Andriy Gapon a...@icyb.net.ua wrote: Which also brings the question - what arch(s) is affected? I tested on amd64. This should explain it. It looks to me like i386 uses kern/link_elf.c as its linker, while amd64 uses kern/link_elf_obj.c. link_elf.c can only find the sections containing the sysinits(and some related things) via the magic symbols. link_elf_obj.c seems to understand ELF objects much better and doesn't need those symbols to be present. It just looks up the section that contains the sysinits directly via the ELF metadata that is already present. As far as I can tell, amd64 is the only arch in the tree that uses link_elf_obj.c, so all other arches may be affected. I have to admit that I'm more than a little surprised that this problem does not affect modules that in src, but maybe that's because I don't know all that much about FreeBSD's build infrastructure. Are the src modules being linked with a linker script that is not being used for out-of-src modules? Are the people affected by this not using the base compiler to build ports?(I see that this affects PC-BSD as well, and I'd be a little surprised to learn that it wasn't using the base compiler). The link line that I gave was a hack. The proper solution is to use a linker script that unconditionally puts the magic symbols in. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1
on 23/06/2010 18:03 Ryan Stone said the following: On Wed, Jun 23, 2010 at 3:10 AM, Andriy Gapon a...@icyb.net.ua wrote: Which also brings the question - what arch(s) is affected? I tested on amd64. This should explain it. It looks to me like i386 uses kern/link_elf.c as its linker, while amd64 uses kern/link_elf_obj.c. link_elf.c can only find the sections containing the sysinits(and some related things) via the magic symbols. link_elf_obj.c seems to understand ELF objects much better and doesn't need those symbols to be present. It just looks up the section that contains the sysinits directly via the ELF metadata that is already present. Yes, you are absolutely correct. This comes from the fact that amd64 uses simple objects files (aka .o) as kernel modules and i386 uses full-blow dso. As far as I can tell, amd64 is the only arch in the tree that uses link_elf_obj.c, so all other arches may be affected. I have to admit that I'm more than a little surprised that this problem does not affect modules that in src, but maybe that's because I don't know all that much about FreeBSD's build infrastructure. Are the src modules being linked with a linker script that is not being used for out-of-src modules? No, we don't have any special linker script for modules. Are the people affected by this not using the base compiler to build ports?(I see that this affects PC-BSD as well, and I'd be a little surprised to learn that it wasn't using the base compiler). I think that even out-of-base modules still use the same module build infrastructure (bsd.kmod.mk). At least this is the case for cuse4bsd. The link line that I gave was a hack. The proper solution is to use a linker script that unconditionally puts the magic symbols in. Module link process on i386 is like this (simplified): 1) combine object files into a single object file mod.kld ld -r -o mod.kld 1.o 2.o 2) convert it to dso ld -Bshareable -d -warn-common -o mod.ko mod.kld I believe that __start/__stop symbols for sections should be automatically added at step 2 by linker. Reference: http://sourceware.org/binutils/docs/ld/Orphan-Sections.html#Orphan-Sections -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1
On Wed, Jun 23, 2010 at 11:03:45AM -0400, Ryan Stone wrote: I have to admit that I'm more than a little surprised that this problem does not affect modules that in src, but maybe that's because I don't know all that much about FreeBSD's build infrastructure. Are the src modules being linked with a linker script that is not being used for out-of-src modules? Are the people affected by this not using the base compiler to build ports?(I see that this affects PC-BSD as well, and I'd be a little surprised to learn that it wasn't using the base compiler). I had the problem on i386, base compiler. It also affects the sample module in /usr/share/examples/kld/cdev/ which also uses the base compiler, if you want a case w/o th eports infrastructure. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgphyY3qX0WQf.pgp Description: PGP signature
Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)
On Wed, Jun 23, 2010 at 08:45:31AM -0700, Ted Faber wrote: On Wed, Jun 23, 2010 at 11:03:45AM -0400, Ryan Stone wrote: I have to admit that I'm more than a little surprised that this problem does not affect modules that in src, but maybe that's because I don't know all that much about FreeBSD's build infrastructure. Are the src modules being linked with a linker script that is not being used for out-of-src modules? Are the people affected by this not using the base compiler to build ports?(I see that this affects PC-BSD as well, and I'd be a little surprised to learn that it wasn't using the base compiler). I had the problem on i386, base compiler. It also affects the sample module in /usr/share/examples/kld/cdev/ which also uses the base compiler, if you want a case w/o the ports infrastructure. Just so it gets into Google: Andriy Gapon went a few rounds of debugging with me and it turns out that the problem was that the binutils port had installed a loader in /usr/local/bin/ld that was incompatible with the module system. (/usr/local/bin/ preceeds /usr/bin in my path so I can use the lpr commands from cupsd, though it's evidently a bit of a dangerous idea.) Basically if the linker you're using to compile isn't /usr/bin/ld you may have problems building kernel modules. The easiest way to detect this is to get the -v output (version number) from the linker in use and compare it against /usr/bin/ld . I was able to do that by adding LDFLAGS += -v to the Makefile in question. Thanks Andriy! -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgp0SF5iLkhfs.pgp Description: PGP signature
Re: amd64 kernel modules: mapping sections to addresses
on 22/06/2010 00:34 Andriy Gapon said the following:
gdb change - I'd rather do it via kld_current_sos,
kld_relocate_section_addresses. I'd like to avoid changing common gdb code
for
a variety of reasons.
I came up with the following patch.
EXEC_P and DYNAMIC flags are bfd library equivalents of ET_EXEC and ET_DYN elf
flags. Absence of both of these flags means ET_REL, which is a type of our
amd64 kernel modules.
The code all resides in kld.c and acts only kernel modules that are either
auto-loaded via kld_current_sos or explicitly added with add-kld.
I used a static variable in kld_relocate_section_addresses because that function
is called on each section sequentially, so current offset can not be stored on
stack. The offset is reset to module's load address when see that we are called
with first section. Alternative is to glimpse at previous section's end address
as you did. So the code depends on sections being passed in forward sequential
order.
How does this look?
Could you please test it?
diff --git a/gnu/usr.bin/gdb/kgdb/kld.c b/gnu/usr.bin/gdb/kgdb/kld.c
index 716a67c..d5ba20a 100644
--- a/gnu/usr.bin/gdb/kgdb/kld.c
+++ b/gnu/usr.bin/gdb/kgdb/kld.c
@@ -198,12 +198,32 @@ find_kld_address (char *arg, CORE_ADDR *address)
}
static void
+adjust_section_address (struct section_table *sec, CORE_ADDR *curr_base)
+{
+ struct bfd_section *asect = sec-the_bfd_section;
+ bfd *abfd = sec-bfd;
+
+ if ((abfd-flags (EXEC_P | DYNAMIC)) != 0) {
+ sec-addr += *curr_base;
+ sec-endaddr += *curr_base;
+ return;
+ }
+
+ *curr_base = align_power(*curr_base,
+ bfd_get_section_alignment(abfd, asect));
+ sec-addr = *curr_base;
+ sec-endaddr = sec-addr + bfd_section_size(abfd, asect);
+ *curr_base = sec-endaddr;
+}
+
+static void
load_kld (char *path, CORE_ADDR base_addr, int from_tty)
{
struct section_addr_info *sap;
struct section_table *sections = NULL, *sections_end = NULL, *s;
struct cleanup *cleanup;
bfd *bfd;
+ CORE_ADDR curr_addr;
int i;
/* Open the kld. */
@@ -224,10 +244,9 @@ load_kld (char *path, CORE_ADDR base_addr, int from_tty)
if (build_section_table (bfd, sections, sections_end))
error(\%s\: can't find file sections, path);
cleanup = make_cleanup(xfree, sections);
- for (s = sections; s sections_end; s++) {
- s-addr += base_addr;
- s-endaddr += base_addr;
- }
+ curr_addr = base_addr;
+ for (s = sections; s sections_end; s++)
+ adjust_section_address(s, curr_addr);
/* Build a section addr info to pass to symbol_file_add(). */
sap = build_section_addr_info_from_section_table (sections,
@@ -284,9 +303,12 @@ kgdb_add_kld_cmd (char *arg, int from_tty)
static void
kld_relocate_section_addresses (struct so_list *so, struct section_table *sec)
{
+ static CORE_ADDR curr_addr;
+
+ if (sec == so-sections)
+ curr_addr = so-lm_info-base_address;
- sec-addr += so-lm_info-base_address;
- sec-endaddr += so-lm_info-base_address;
+ adjust_section_address(sec, curr_addr);
}
static void
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
[HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1
Hi, I'm creating a new thread on this issue. On Tue, Jun 22, 2010 at 04:39:17PM -0400, Ryan Stone wrote: I saw similar behaviour a couple of years ago when I switched from using gcc 4.0.2 to gcc 4.3.0 to compile some out-of-tree KLD modules. The problem ended up being a change in the linker script used by GNU ld for linking kernel modules. It used to always put some magic symbols used by the linker to implement things like sysinits into the module. It was changed to only provide those symbols, which apparently means that the linker would discard those symbols if nothing referenced them(and nothing did reference them). I had to work around it by adding the following to my link line: -u __start_set_sysinit_set -u __start_set_sysuninit_set \ -u __start_set_sysctl_set -u __start_set_modmetadata_set \ -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ -u __stop_set_sysctl_set -u __stop_set_modmetadata_set It appears many kmods are broken because the linker is stripping away static data declared with the section attribute in FreeBSD 8.1-RC1. cite I added those lines to the LDFLAGS in Makefile.kmod in the cuse4bsd port made the module and the result loads and creates the /dev/cuse file. Here's a diff relative to /usr/ports/multimedia/cuse4bsd-kmod/work/cuse4bsd-kmod-0.1.11 just so it's clear what I did. --- Makefile.kmod.orig 2010-02-11 03:28:02.0 -0800 +++ Makefile.kmod 2010-06-22 14:02:52.0 -0700 @@ -30,4 +30,10 @@ KMOD= cuse4bsd SRCS= cuse4bsd_kmod.c device_if.h bus_if.h vnode_if.h +LDFLAGS += -u __start_set_sysinit_set -u __start_set_sysuninit_set \ + -u __start_set_sysctl_set -u __start_set_modmetadata_set \ + -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ + -u __stop_set_sysctl_set -u __stop_set_modmetadata_set + + .include bsd.kmod.mk Running nm -o on the two modules, the difference seems to be that the -u results in some additional absolute symbols being defined: Bad module: $ nm -o /boot/modules/cuse4bsd.ko| grep sys /boot/modules/cuse4bsd.ko:275c r __set_sysinit_set_sym_cuse_kern_init_sys_init /boot/modules/cuse4bsd.ko:2758 r __set_sysuninit_set_sym_cuse_kern_uninit_sys_uninit /boot/modules/cuse4bsd.ko:3194 d cuse_kern_init_sys_init /boot/modules/cuse4bsd.ko:3184 d cuse_kern_uninit_sys_uninit Good module: $ nm -o ./cuse4bsd.ko | grep sys ./cuse4bsd.ko:28cc r __set_sysinit_set_sym_cuse_kern_init_sys_init ./cuse4bsd.ko:28c8 r __set_sysuninit_set_sym_cuse_kern_uninit_sys_uninit ./cuse4bsd.ko: U __start_set_sysctl_set ./cuse4bsd.ko:28cc A __start_set_sysinit_set ./cuse4bsd.ko:28c8 A __start_set_sysuninit_set ./cuse4bsd.ko: U __stop_set_sysctl_set ./cuse4bsd.ko:28d0 A __stop_set_sysinit_set ./cuse4bsd.ko:28cc A __stop_set_sysuninit_set ./cuse4bsd.ko:3194 d cuse_kern_init_sys_init ./cuse4bsd.ko:3184 d cuse_kern_uninit_sys_uninit /cite --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1
On Wed, Jun 23, 2010 at 02:38:06AM +0200, Hans Petter Selasky wrote: It appears many kmods are broken because the linker is stripping away static data declared with the section attribute in FreeBSD 8.1-RC1. cite I added those lines to the LDFLAGS in Makefile.kmod in the cuse4bsd port made the module and the result loads and creates the /dev/cuse file. Hi. I'm the fellow in Hans's cite.../cite. If someone's looking into this, it's worth mentioning that the sample cdev kmodule in /usr/share/examples/kld/cdev/ also exhibits the behavior. On my 8.1-PRERELEASE system that module does not create the /dev/cedv device, but if you add the line LDFLAGS += -u __start_set_sysinit_set -u __start_set_sysuninit_set \ -u __start_set_sysctl_set -u __start_set_modmetadata_set \ -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ -u __stop_set_sysctl_set -u __stop_set_modmetadata_set right before the .include bsd.kmod.mk in /usr/share/examples/kld/cdev/module/Makefile and remake everything, the module creates the /dev/cdev file when it's loaded. That magical line was suggested by Ryan Stone in another thread: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=120718+0+current/freebsd-hackers Happy hunting, and I'm happy to test patches or provide more information. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgpBir6Orw3Ec.pgp Description: PGP signature
amd64 kernel modules: mapping sections to addresses
I've noticed that on amd64 addresses (sh_addr) of all sections in a kernel module are zeros. This is unlike kernel itself and i386 modules. Kernel linker maps SHT_PROGBITS and SHT_NOBITS sections sequentially starting at a certain base address and taking into account their sizes and alignment requirements. On the other hand, kgdb calculates section address as module base address plus sh_addr of the section. Which puts all sections, e.g. .text, .data, .bss, at the same address. This is correct only for .text which is normally the first section described in a header. DTrace situation is even worse, because don't even take into account module base address, not speaking of section relative addresses. Perhaps we should put some sh_addr values into amd64 kernel modules that would match calculations done in link_elf_load_file. Or should we replicate logic from link_elf_load_file in all places that need to map loaded module's sections to load addresses? What do you think? Thanks! P.S. As I understand CTF data includes a symbol table. What kind of symbol addresses is used there? Are they relative within a corresponding section? Or something else? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: amd64 kernel modules: mapping sections to addresses
On Monday 21 June 2010 10:39:08 am Andriy Gapon wrote: I've noticed that on amd64 addresses (sh_addr) of all sections in a kernel module are zeros. This is unlike kernel itself and i386 modules. Kernel linker maps SHT_PROGBITS and SHT_NOBITS sections sequentially starting at a certain base address and taking into account their sizes and alignment requirements. On the other hand, kgdb calculates section address as module base address plus sh_addr of the section. Which puts all sections, e.g. .text, .data, .bss, at the same address. This is correct only for .text which is normally the first section described in a header. DTrace situation is even worse, because don't even take into account module base address, not speaking of section relative addresses. Perhaps we should put some sh_addr values into amd64 kernel modules that would match calculations done in link_elf_load_file. Or should we replicate logic from link_elf_load_file in all places that need to map loaded module's sections to load addresses? What do you think? Thanks! P.S. As I understand CTF data includes a symbol table. What kind of symbol addresses is used there? Are they relative within a corresponding section? Or something else? np@ has a patch to gdb to fix this for kgdb. I haven't committed it as it patched gdb internals and wasn't in a kgdb-specific place, but I'm not sure of a better way to fix kgdb. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: amd64 kernel modules: mapping sections to addresses
on 21/06/2010 18:43 John Baldwin said the following: np@ has a patch to gdb to fix this for kgdb. I haven't committed it as it patched gdb internals and wasn't in a kgdb-specific place, but I'm not sure of a better way to fix kgdb. Oh, yes, section mapping is done in common gdb code. Perhaps kld.c shouldn't call build_section_table, but directly call bfd_map_over_sections with a custom variant of add_to_section_table? Can you please share the patch? Still, what about a small tool, elf(3)-base porgram or objdump+objcopy shell script, that would set section addresses in amd64 .ko (relocatable object file) similarly to how they are set in i386 .ko (full-blown DSO)? Or is this too much useless hassle? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: amd64 kernel modules: mapping sections to addresses
On Monday 21 June 2010 11:57:17 am Andriy Gapon wrote: on 21/06/2010 18:43 John Baldwin said the following: np@ has a patch to gdb to fix this for kgdb. I haven't committed it as it patched gdb internals and wasn't in a kgdb-specific place, but I'm not sure of a better way to fix kgdb. Oh, yes, section mapping is done in common gdb code. Perhaps kld.c shouldn't call build_section_table, but directly call bfd_map_over_sections with a custom variant of add_to_section_table? Can you please share the patch? It was deeper level than that, I'd have to dig it up. Still, what about a small tool, elf(3)-base porgram or objdump+objcopy shell script, that would set section addresses in amd64 .ko (relocatable object file) similarly to how they are set in i386 .ko (full-blown DSO)? Or is this too much useless hassle? No idea. If this worked and just let gdb work automatically that would be a nice fix to just put into the build process. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: amd64 kernel modules: mapping sections to addresses
On Mon, Jun 21, 2010 at 04:10:45PM -0400, John Baldwin wrote: On Monday 21 June 2010 11:57:17 am Andriy Gapon wrote: on 21/06/2010 18:43 John Baldwin said the following: np@ has a patch to gdb to fix this for kgdb. I haven't committed it as it patched gdb internals and wasn't in a kgdb-specific place, but I'm not sure of a better way to fix kgdb. Oh, yes, section mapping is done in common gdb code. Perhaps kld.c shouldn't call build_section_table, but directly call bfd_map_over_sections with a custom variant of add_to_section_table? Can you please share the patch? It was deeper level than that, I'd have to dig it up. I'm using this patch these days: http://people.freebsd.org/~np/kgdb+kld+amd64.diff The changes to the kernel linker were not required originally. See this for why they had to be made: http://lists.freebsd.org/pipermail/freebsd-hackers/2009-November/030093.html The patch is quite crude and I have no idea how it behaves on other platforms. Regards, Navdeep Still, what about a small tool, elf(3)-base porgram or objdump+objcopy shell script, that would set section addresses in amd64 .ko (relocatable object file) similarly to how they are set in i386 .ko (full-blown DSO)? Or is this too much useless hassle? No idea. If this worked and just let gdb work automatically that would be a nice fix to just put into the build process. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: amd64 kernel modules: mapping sections to addresses
on 21/06/2010 23:44 Navdeep Parhar said the following: On Mon, Jun 21, 2010 at 04:10:45PM -0400, John Baldwin wrote: On Monday 21 June 2010 11:57:17 am Andriy Gapon wrote: on 21/06/2010 18:43 John Baldwin said the following: np@ has a patch to gdb to fix this for kgdb. I haven't committed it as it patched gdb internals and wasn't in a kgdb-specific place, but I'm not sure of a better way to fix kgdb. Oh, yes, section mapping is done in common gdb code. Perhaps kld.c shouldn't call build_section_table, but directly call bfd_map_over_sections with a custom variant of add_to_section_table? Can you please share the patch? It was deeper level than that, I'd have to dig it up. I'm using this patch these days: http://people.freebsd.org/~np/kgdb+kld+amd64.diff The changes to the kernel linker were not required originally. See this for why they had to be made: http://lists.freebsd.org/pipermail/freebsd-hackers/2009-November/030093.html The patch is quite crude and I have no idea how it behaves on other platforms. Thanks a lot! These are exact issues that I hit and the patches are what I think they should be, take or give. I don't think they are really crude. I will try to get them committed. Kernel linker change is good as is, I'd just like to move the zero size check before the switch statement. gdb change - I'd rather do it via kld_current_sos, kld_relocate_section_addresses. I'd like to avoid changing common gdb code for a variety of reasons. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: amd64 kernel modules: mapping sections to addresses
On Tue, Jun 22, 2010 at 12:34:49AM +0300, Andriy Gapon wrote: on 21/06/2010 23:44 Navdeep Parhar said the following: On Mon, Jun 21, 2010 at 04:10:45PM -0400, John Baldwin wrote: On Monday 21 June 2010 11:57:17 am Andriy Gapon wrote: on 21/06/2010 18:43 John Baldwin said the following: np@ has a patch to gdb to fix this for kgdb. I haven't committed it as it patched gdb internals and wasn't in a kgdb-specific place, but I'm not sure of a better way to fix kgdb. Oh, yes, section mapping is done in common gdb code. Perhaps kld.c shouldn't call build_section_table, but directly call bfd_map_over_sections with a custom variant of add_to_section_table? Can you please share the patch? It was deeper level than that, I'd have to dig it up. I'm using this patch these days: http://people.freebsd.org/~np/kgdb+kld+amd64.diff The changes to the kernel linker were not required originally. See this for why they had to be made: http://lists.freebsd.org/pipermail/freebsd-hackers/2009-November/030093.html The patch is quite crude and I have no idea how it behaves on other platforms. Thanks a lot! These are exact issues that I hit and the patches are what I think they should be, take or give. I don't think they are really crude. I will try to get them committed. Kernel linker change is good as is, I'd just like to move the zero size check before the switch statement. I'm not so sure about this. There is code inside the second switch that runs whether sh_size is 0 or not. Either all of it is pointless code (when sh_size is 0) or or you'll make sure that it still runs, right? Regards, Navdeep gdb change - I'd rather do it via kld_current_sos, kld_relocate_section_addresses. I'd like to avoid changing common gdb code for a variety of reasons. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: amd64 kernel modules: mapping sections to addresses
on 22/06/2010 01:00 Navdeep Parhar said the following: I'm not so sure about this. There is code inside the second switch that runs whether sh_size is 0 or not. Either all of it is pointless code (when sh_size is 0) or or you'll make sure that it still runs, right? It's definitely pointless. [IMHO :-)] -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Mutually exclusive kernel modules
Hi, I'm writing a new kernel module which can not be run with another module. If both run then bad things will happen and the kernel will fall over. Fixing the modules so they can be run together is not a option, so I wanted to code something in this new module which would A) Check if the other module is already running and thus refuse to start. and B) Stop the other module from loading in the future. So is there a way to do this? thanks Andrew ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: where to start on kernel modules and NSS?
Z.C.B. wrote: Have just been looking at sitting down and looking at writing a few things, but I am a bit lost on where to start. Any suggestions on things to read in regards to NSS and writing kernel modules? These are not similar things and you don't need kernel modules for NSS. For kernel modules, you might try reading: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/index.html http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/index.html http://www.freebsd.org/doc/en_US.ISO8859-1/articles/geom-class/kernelprog.html signature.asc Description: OpenPGP digital signature
Re: where to start on kernel modules and NSS?
On Tue, 03 Jul 2007 11:04:17 +0200 Ivan Voras [EMAIL PROTECTED] mentioned: Z.C.B. wrote: Have just been looking at sitting down and looking at writing a few things, but I am a bit lost on where to start. Any suggestions on things to read in regards to NSS and writing kernel modules? These are not similar things and you don't need kernel modules for NSS. For kernel modules, you might try reading: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/index.html http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/index.html http://www.freebsd.org/doc/en_US.ISO8859-1/articles/geom-class/kernelprog.html Also, this document can serve a very good introduction: http://caia.swin.edu.au/reports/070622A/CAIA-TR-070622A.pdf -- Stanislav Sedov ST4096-RIPE pgp3fuiROpdZ8.pgp Description: PGP signature
build /* only */ the required kernel modules
Hi Hackers, I'm stripping down my kernel, and I use the MODULES_OVERRIDE option in make.conf Here's the question: I need support for if_fwe and ng_bluetooth, but I can't find a way to build /*ONLY*/ the required modules, instead of building /*EVERYTHING*/ under firewire/ and under netgraph/ Adding netgraph/bluetooth and firewire/fwe in the MODULES_OVERRIDE list won't build the parent netgraph and firewire modules, but adding netgraph and firewire will build lots of unneeded and unwanted modules. Example: find /boot/kernel/ -name ng_* | wc -l 58 when, /sys/modules/netgraph/bluetooth/Makefile just lists 8 modules as dependencies. How could I get rid of the ~50 unneeded modules? Same thing for firewire, where unneeded if_fwip, sbp and sbp_targ are also built, along with firewire and if_fwe. Thanx in advance, -- Pietro Cerutti ICQ: 117293691 PGP: 0x9571F78E - ASCII Ribbon Campaign - against HTML e-mail and proprietary attachments www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: build /* only */ the required kernel modules
Pietro Cerutti wrote: Adding netgraph/bluetooth and firewire/fwe in the MODULES_OVERRIDE list won't build the parent netgraph and firewire modules, but adding netgraph and firewire will build lots of unneeded and unwanted modules. netgraph/netgraph and firewire/firewire. -- Skip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Compiling kernel/modules without INET?
Howdy, One of my new years resolutions was to become a bit more masochistic, so I set out to see if I could build a kernel (and modules) without options INET on HEAD. This works flawlessly for the kernel part, but there are tons of issues when building modules -- various problems encountered during make depend and make. So far there appear to be four different classes of errors: 1) Failures during make depend due to #error directives hit when INET is not defined. 2) #includes which are always needed but are only pulled in (implicitly) when INET is defined 3) Small blocks of code (variable declarations and tests) which are not wrapped with #ifdef INET (or other #defines), or simply wrapped with the wrong #ifdef 4) Larger messes such as GRE's hard-coded dependence on INET; SLIP/PPP's dependence on packet compress code, etc. I have what I think are valid fixes for the first 3 issues, but I know I'm just making a mess of things to resolve the last issue. Before I spit and polish these patches for public consumption, I want to know if this is even a worthy project. I know there are benefits simply because we should do the right thing, but I'm sure I'm wading into murky waters. Any guidance would be appreciated. Regards, -- Matt Emmerton ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
how to write the dynamic kernel modules [Re: Regarding FreeBSd]
On 2004-06-16 11:35:33 +0530, ravi wrote: Hi, I wanted to know how to write the dynamic kernel modules in FreeBSD. Please send me the relevant information. Regards, N Ravi Hi Ravi, I forwarded your mail to the FreeBSD mailing list [EMAIL PROTECTED] You should read the FreeBSD Architecture Handbook, Chapter 13 Writing FreeBSD Device Drivers http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/driverbasics-kld.html -Wolfram -- Wolfram Schneider [EMAIL PROTECTED] http://wolfram.schneider.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel modules programming: struct proc question
Toni wrote: pid_t is an unsigned number, so try %u in printf() instead. There's no need to cast a pid_t to int. Doesn't help. It shows wrong pid's again... -Roman Bogorodskiy pgp0.pgp Description: PGP signature
Re: kernel modules programming: struct proc question
pid_t is signed int type, or am I missing something?
try this one:
static int
new_open (struct proc *p, register struct open_args *uap)
{
pid_t pid;
pid = p-p_pid;
printf(open(2): pid: %d\n, pid);
return (open(p,uap));
}
On Wed, 17 Mar 2004 17:24:51 +0300, Roman Bogorodskiy
[EMAIL PROTECTED] wrote:
Toni wrote:
pid_t is an unsigned number, so try %u in printf() instead.
There's no need to cast a pid_t to int.
Doesn't help. It shows wrong pid's again...
-Roman Bogorodskiy
--
Artis
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel modules programming: struct proc question
On Tuesday 16 March 2004 11:39 am, Roman Bogorodskiy wrote:
Hi,
I hope it's a right place for kernel module programming related
questions, in another case I'd be glad if you point me to the right
maillist.
So, my aim is to log every file opening in `/tmp' dir. I've wrote a simple
syscall module which replaces open(2) syscall. My new open(2) looks
like this:
---cut 8---
static int
new_open(struct proc *p, register struct open_args *uap)
{
char name[NAME_MAX];
size_t size;
if((const void*)copyinstr(uap-path, name,
NAME_MAX, size) == (const void*)EFAULT)
return(EFAULT);
if (name[0] == '/' name[1] == 't' name[2] == 'm'
name[3] == 'p' name[4] == '/') {
printf(open(2): %s pid: %i\n, name, (int)p-p_pid);
}
return (open(p, uap));
}
---cut 9---
But instead of a real pid I see something strange in logs, something
like this:
Mar 16 19:15:44 nov kernel: open(2): /tmp/asfdasfsaf pid: -1002890624
What am I doing wrong?
If this is on current, then the first arg to your syscall should be 'struct
thread *td', and you should try to printf td-td_proc-p_pid to get the pid.
Also, you might consider using strncmp() to make the code a bit easier to
read, i.e.:
if (strncmp(name, /tmp/, 5) == 0)
printf(open(2): %s by pid %d (%s)\n, name, td-td_proc-p_pid,
td-td_proc-p_comm);
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve = http://www.FreeBSD.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel modules programming: struct proc question
On Wed, Mar 17 2004 (17:00:02 +0200), Artis Caune wrote: pid_t is signed int type, or am I missing something? You are right, pid_t is __int32_t, which is signed, so %d is the correct format. I assumed that in this case, the signed integer overflowed, so maybe interpreting it as an unsigned integer would make more sense. However, I don't know what could cause a pid_t to become that large. On 5.x, fork1() tries to find an unused pid for a new process and checks if it lies between 100 and PID_MAX. Cheers, Toni ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel modules programming: struct proc question
On Wed, Mar 17, 2004 at 04:45:30PM +0100, Toni Andjelkovic wrote: On Wed, Mar 17 2004 (17:00:02 +0200), Artis Caune wrote: pid_t is signed int type, or am I missing something? You are right, pid_t is __int32_t, which is signed, so %d is the correct format. That's only correct for machines with 32-bit ints. In any case, POSIX only specifies that pid_t is a signed integer type... it could be any size supported by the implementation. For portability, you probably want to cast to the `biggest' type and use the appropriate printf specifier, e.g. printf(%ld, (long)pid_t); or printf(%jd, (intmax_t)pid_t); // C99 Cheers, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel modules programming: struct proc question
John wrote: Also, you might consider using strncmp() to make the code a bit easier to read, i.e.: if (strncmp(name, /tmp/, 5) == 0) printf(open(2): %s by pid %d (%s)\n, name, td-td_proc-p_pid, td-td_proc-p_comm); Thank you very much, it works. -Roman Bogorodskiy pgp0.pgp Description: PGP signature
Re: kernel modules programming: struct proc question
On Wed, Mar 17, 2004 at 09:36:39PM +0300, Roman Bogorodskiy wrote: static int new_open(struct proc *p, register struct open_args *uap) Er, the first argument passed to a system call in 5.x is a `struct thread', not a `struct proc'. Cheers, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
kernel modules programming: struct proc question
Hi,
I hope it's a right place for kernel module programming related
questions, in another case I'd be glad if you point me to the right
maillist.
So, my aim is to log every file opening in `/tmp' dir. I've wrote a simple
syscall module which replaces open(2) syscall. My new open(2) looks
like this:
---cut 8---
static int
new_open(struct proc *p, register struct open_args *uap)
{
char name[NAME_MAX];
size_t size;
if((const void*)copyinstr(uap-path, name,
NAME_MAX, size) == (const void*)EFAULT)
return(EFAULT);
if (name[0] == '/' name[1] == 't' name[2] == 'm'
name[3] == 'p' name[4] == '/') {
printf(open(2): %s pid: %i\n, name, (int)p-p_pid);
}
return (open(p, uap));
}
---cut 9---
But instead of a real pid I see something strange in logs, something
like this:
Mar 16 19:15:44 nov kernel: open(2): /tmp/asfdasfsaf pid: -1002890624
What am I doing wrong?
-Roman Bogorodskiy
pgp0.pgp
Description: PGP signature
Re: kernel modules programming: struct proc question
On Tue, Mar 16 2004 (19:39:56 +0300), Roman Bogorodskiy wrote: [...] printf(open(2): %s pid: %i\n, name, (int)p-p_pid); [...] Mar 16 19:15:44 nov kernel: open(2): /tmp/asfdasfsaf pid: -1002890624 pid_t is an unsigned number, so try %u in printf() instead. There's no need to cast a pid_t to int. Cheers, Toni ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel modules programming: struct proc question
On Tue, Mar 16, 2004 at 07:39:56PM +0300, Roman Bogorodskiy wrote: + I hope it's a right place for kernel module programming related + questions, in another case I'd be glad if you point me to the right + maillist. + + So, my aim is to log every file opening in `/tmp' dir. I've wrote a simple + syscall module which replaces open(2) syscall. My new open(2) looks + like this: Keep in mind, that there is no need to open file by giving its full path. For example: % cd /tmp % cat ./foo or: % ln -s /tmp/foo ~/bar % cat bar -- Pawel Jakub Dawidek http://www.FreeBSD.org [EMAIL PROTECTED] http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! pgp0.pgp Description: PGP signature
Re: compressed kernel modules
In message: [EMAIL PROTECTED] masta [EMAIL PROTECTED] writes: : Does the -CURRENT kldload(8), and/or loader(8), understand how to : decompress gzip/bzip kernel modules? I'm assuming it is possible, but I : haven't seen that done in the wild, or documented. Not really. The boot loader loader can. Without help, kldload can't. However, I have a small script that does a simple: #!/bin/sh cp /modules/$1.ko.gz /tmp gunzip /tmp/$1.ko.gz kldload /tmp/$1.ko rm /tmp/$1.ko Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
compressed kernel modules
Howdy, Does the -CURRENT kldload(8), and/or loader(8), understand how to decompress gzip/bzip kernel modules? I'm assuming it is possible, but I haven't seen that done in the wild, or documented. Thanks in advance. __ __ _ | \/ | __ _ ___| |_ __ _ | |\/| |/ _` / __| __/ _` | | | | | (_| \__ \ || (_| | |_| |_|\__,_|___/\__\__,_| unzip ; strip ; touch ; finger ; mount ; fsck ; more ; yes ; umount ; sleep [EMAIL PROTECTED] http://wifibsd.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Build options for kernel modules
On Fri, Mar 21, 2003 at 06:32:17PM +0300, Yar Tikhiy wrote: Hi there, Excuse my stupid question, but I seem to have no time to do the investigation by myself right now so I'd be glad to receive a brief answer from someone who has the information. As far as I can see, kernel modules should be built along with the kernel for the only reason of keeping their mutual interfaces in sync, has a source file defining such an interface changed. Is there currently no way to go further and affect a kernel module's built-in features with kernel config file options, besides modifying makefiles in /sys/modules? There is. It's called ``makeoptions''. It's passed to both kernel and modules builds. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age pgp0.pgp Description: PGP signature
Re: Build options for kernel modules
On Fri, Mar 21, 2003 at 06:32:17PM +0300, Yar Tikhiy wrote: Hi there, Excuse my stupid question, but I seem to have no time to do the investigation by myself right now so I'd be glad to receive a brief answer from someone who has the information. As far as I can see, kernel modules should be built along with the kernel for the only reason of keeping their mutual interfaces in sync, has a source file defining such an interface changed. Is there currently no way to go further and affect a kernel module's built-in features with kernel config file options, besides modifying makefiles in /sys/modules? I think this isn't so. I have been already tried to compile some modules without compiling kernel and this trye has successful result, but without change options. I think modules must be build with same or less imports and same or more export to be correct for loading. -- With best wishes Nikolay mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Build options for kernel modules
On Fri, Mar 21, 2003 at 05:39:07PM +0200, Nikolay Y. Orlyuk wrote: On Fri, Mar 21, 2003 at 06:32:17PM +0300, Yar Tikhiy wrote: Hi there, Excuse my stupid question, but I seem to have no time to do the investigation by myself right now so I'd be glad to receive a brief answer from someone who has the information. As far as I can see, kernel modules should be built along with the kernel for the only reason of keeping their mutual interfaces in sync, has a source file defining such an interface changed. Is there currently no way to go further and affect a kernel module's built-in features with kernel config file options, besides modifying makefiles in /sys/modules? I think this isn't so. I have been already tried to compile some modules without compiling kernel and this trye has successful result, but without change options. I think modules must be build with same or less imports and same or more export to be correct for loading. Yeah, it's all right to compile modules w/o the kernel, but that's not exactly what I was asking about. My question was whether option FOO lines from a kernel configuration file could influence modules. -- Yar To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Build options for kernel modules
On Fri Mar 21, 2003 at 07:16:58PM +0300, Yar Tikhiy wrote: On Fri, Mar 21, 2003 at 05:39:07PM +0200, Nikolay Y. Orlyuk wrote: On Fri, Mar 21, 2003 at 06:32:17PM +0300, Yar Tikhiy wrote: Hi there, Excuse my stupid question, but I seem to have no time to do the investigation by myself right now so I'd be glad to receive a brief answer from someone who has the information. As far as I can see, kernel modules should be built along with the kernel for the only reason of keeping their mutual interfaces in sync, has a source file defining such an interface changed. Is there currently no way to go further and affect a kernel module's built-in features with kernel config file options, besides modifying makefiles in /sys/modules? I think this isn't so. I have been already tried to compile some modules without compiling kernel and this trye has successful result, but without change options. I think modules must be build with same or less imports and same or more export to be correct for loading. Yeah, it's all right to compile modules w/o the kernel, but that's not exactly what I was asking about. My question was whether option FOO lines from a kernel configuration file could influence modules. I'm pretty sure they do. A great example is IPFIREWALL_* options: if they don't influence the module, I think we have a problem. ;) A. -- Advertisers, not governments, are the primary censors of media content in the United States today. - C. Edwin Baker http://www.ad-mad.co.uk/quotes/freespeech.htm pgp0.pgp Description: PGP signature
Re: Build options for kernel modules
On Fri, Mar 21, 2003 at 05:35:22PM +0200, Ruslan Ermilov wrote: On Fri, Mar 21, 2003 at 06:32:17PM +0300, Yar Tikhiy wrote: Hi there, Excuse my stupid question, but I seem to have no time to do the investigation by myself right now so I'd be glad to receive a brief answer from someone who has the information. As far as I can see, kernel modules should be built along with the kernel for the only reason of keeping their mutual interfaces in sync, has a source file defining such an interface changed. Is there currently no way to go further and affect a kernel module's built-in features with kernel config file options, besides modifying makefiles in /sys/modules? There is. It's called ``makeoptions''. It's passed to both kernel and modules builds. I beg your pardon, but makeoptions is just next to editing makefiles in /sys/modules. My dream was that specifying, e.g., options IPFIREWALL_VERBOSE would result in building ipfw.ko inherently chatty :-) BTW, Ruslan, let me ask you another question, as you've been recently working at kern.mk files. Is it on purpose that the target kernel-cleandir doesn't invoke kernel-cleandepend? I've been sure that by common practice cleandir should remove dependency files... -- Yar To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Build options for kernel modules
On Fri, 21 Mar 2003, The Anarcat wrote: TAOn Fri Mar 21, 2003 at 07:16:58PM +0300, Yar Tikhiy wrote: TA On Fri, Mar 21, 2003 at 05:39:07PM +0200, Nikolay Y. Orlyuk wrote: TA On Fri, Mar 21, 2003 at 06:32:17PM +0300, Yar Tikhiy wrote: TA Hi there, TA TA Excuse my stupid question, but I seem to have no time to do the TA investigation by myself right now so I'd be glad to receive a brief TA answer from someone who has the information. TA TA As far as I can see, kernel modules should be built along with the TA kernel for the only reason of keeping their mutual interfaces in TA sync, has a source file defining such an interface changed. Is TA there currently no way to go further and affect a kernel module's TA built-in features with kernel config file options, besides modifying TA makefiles in /sys/modules? TA I think this isn't so. I have been already tried to compile some modules TA without compiling kernel and this trye has successful result, but without TA change options. TA I think modules must be build with same or less imports and same or more export to be correct TA for loading. TA TA Yeah, it's all right to compile modules w/o the kernel, but that's TA not exactly what I was asking about. My question was whether option TA FOO lines from a kernel configuration file could influence modules. TA TAI'm pretty sure they do. A great example is IPFIREWALL_* options: if TAthey don't influence the module, I think we have a problem. ;) How should they? The Makefiles for modules usually create the option files that normally are create by config options themself and set the options to 1. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Build options for kernel modules
On Fri Mar 21, 2003 at 07:47:42PM +0300, Yar Tikhiy wrote: On Fri, Mar 21, 2003 at 11:25:01AM -0500, The Anarcat wrote: On Fri Mar 21, 2003 at 07:16:58PM +0300, Yar Tikhiy wrote: Yeah, it's all right to compile modules w/o the kernel, but that's not exactly what I was asking about. My question was whether option FOO lines from a kernel configuration file could influence modules. I'm pretty sure they do. A great example is IPFIREWALL_* options: if they don't influence the module, I think we have a problem. ;) My testing a yesterday's CURRENT has shown we did have the problem. Everobody is invited to set options IPFIREWALL_DEFAULT_TO_ACCEPT and to load the resulting ipfw.ko on a remote machine without human access ;-))) [small print: it's a joke, don't actually do that.] Woops. -- Nothing incites to money-crimes like great poverty or great wealth. - Mark Twain pgp0.pgp Description: PGP signature
Re: Smarter kernel modules?
On Thu, Mar 06, 2003 at 01:49:20AM -0600, Sean Kelly wrote: +/* + * Define the version. Change the symbol name when things get too + * incompatible. version_5_1 means the 'ABI compatible with FreeBSD 5.1' + */ +char __version_5_1 = 1; ... Wouldn't it make more sense to have a symbol name that doesn't change across versions? Something like '_module_version' perhaps. Then the value of the symbol is the version which the module corresponds to. This would let you use something like kern.osreldate or a per-subsystem version index. No. Warner's trick is that each module includes an unresolved reference to the version symbol (in module.h), which is defined in the kernel. If the kernel run-time loader can't resolve the reference (meaning that the version symbol has changed in the kernel) then it will report and error and refuse to load the module - neither the kernel nor the module need to know anything about versioning. (Though the name needs to be kept aligned in two different files). The actual value of the symbol is irrelevant (though it could potentially be used to differentiate different mostly-compatible kernels). config.h: #define API_VERSION 500100 mymodule.c: long _module_version = API_VERSION; And I presume the kernel then verifies that _module_version in the just-loaded .ko matches the kernel's idea of API_VERSION. Overall, this is equivalent to Warner's approach except that the kernel needs to explicitly check the contents of _module_version (and the loader needs to understand having identical symbols declared in multiple modules - ie _module_version becomes a special name). Another benefit(?) is that if _module_version is missing, you can decide that you don't care about versioning and just load the module. This exists implicitly in Warner's code as well - if there's no reference to the kernel version symbol then the load will succeed whatever the name of the version symbol in the kernel. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Smarter kernel modules?
M. Warner Losh writes: In message: [EMAIL PROTECTED] Sean Kelly [EMAIL PROTECTED] writes: : Has anyone ever considered embedding some sort of identifier in kernel : modules to keep them from being loaded with the wrong kernel? Actually, I was talking about this with Matt Dodd this morning... Whatever we do, lets NOT be anywhere near as fascist as linux. If we implement any kind of versioning, its got to be fine-grained enough that 3rd party binary modules will not get broken by an ABI change in an area of the kernel which they do not care about, or there needs to be a way for a module to opt-out. My company ships a binary driver (ethernet network, and character device) built on 4.1.1-R, and it has continued to work at least until 4.7-R. I'd like to see that same level of ABI stability throughout the 5-STABLE branch. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Smarter kernel modules?
At 2003-03-06T07:09:40Z, Peter Jeremy [EMAIL PROTECTED] writes: 1) If you update any of those kernels, the updated kernel and updated modules will be written into /boot/FOO/ as appropriate. BUT old modules that weren't rebuilt (eg 3rd party modules) will remain in /boot/FOO/. If the new kernel happened to change an API, you're likely to get a panic when you load the old module. Is the new system documented anywhere? I had assumed that it was analogous to Linux's (Debian's, at least) system. I have several entries under /lib/modules: $ ls 2.2.20 2.4.17-k7 2.4.18-k7 2.4.19-k7 Whenever I boot one of the respective kernels, it looks for its modules in /lib/modules/$VERSION so that there's no real possibility for catastrophic interaction. -- Kirk Strauser In Googlis non est, ergo non est. pgp0.pgp Description: PGP signature
Re: Smarter kernel modules?
In message: [EMAIL PROTECTED] Sean Kelly [EMAIL PROTECTED] writes: : On Wed, Mar 05, 2003 at 09:59:01PM -0700, M. Warner Losh wrote: : Here's a simple patch. However, it is a total suck-ass kludge (and : that's being generous). The ABI isn't THE ABI, but rather a : collection of ABIs. These ABIs change slowly and there is a certain : range that work together. Historically, we've been really bad about : bumping version numbers when things change in modules. Also, there's : no built-in versioning in the module names, which makes it harder to : have multiple versions around. As such, the version numbers are set : to 1 and never change. : : My kernel coding skills are severely limited, so please adjust any pointing : and laughing as appropriate. : : ... : +/* : + * Define the version. Change the symbol name when things get too : + * incompatible. version_5_1 means the 'ABI compatible with FreeBSD 5.1' : + */ : +char __version_5_1 = 1; : ... : : Wouldn't it make more sense to have a symbol name that doesn't change : across versions? Something like '_module_version' perhaps. Then the value : of the symbol is the version which the module corresponds to. This would : let you use something like kern.osreldate or a per-subsystem version index. No. We already have __FreeBSD_version that doesn't change. This symbol would ensure that the link would fail. Link fails and then you have to do nothing further to prevent the module from loading. The other option would be to have all modules have an implicit MODULE_DEPENDS on a freebsd moudle that's in the kernel. : Another benefit(?) is that if _module_version is missing, you can decide : that you don't care about versioning and just load the module. This could : be useful for third-party modules that don't want to lock them down to a : specific kernel/API/subsystem version. Not recommended, but optional. No. If you want versioining, you get strict versioning, imho. I don't want an opt-out. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Smarter kernel modules?
In message: [EMAIL PROTECTED] Andrew Gallatin [EMAIL PROTECTED] writes: : My company ships a binary driver (ethernet network, and character : device) built on 4.1.1-R, and it has continued to work at least until : 4.7-R. I'd like to see that same level of ABI stability throughout : the 5-STABLE branch. I'd like to see that too, which is one reason that I'd want a simple, rarely incremented single number. Make it too easy to bump the number, and you get into the mess you have with Linux and complain about. We already have versioning issues with the current modules system we have, but experience over the past two releases has shown that nobody uses it. Also, this isn't anti-foot shooting for -current. On -current you live with the pain, and like it. current module writers haven't been able to bump version reliably in the past 5 years, and I don't think that something magical is going to happen to make them do it now. This is for the production side of FreeBSD, not the bleeding edge. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Smarter kernel modules?
In message: [EMAIL PROTECTED] Peter Jeremy [EMAIL PROTECTED] writes: : Disadvantages: : - Needs grunt-work to write the #defines : - Kernel symbols reported by nm(1) look strange (unless we patch : binutils to understand our versioning scheme). : - May present problems to '##' built symbols. History has shown that people suck at keeping such a complex scheme up to date. Also, it versions functions, but not datta structures. Data strucutre changes are the number 1 cause of ABI breakage we've had over the last 5 years. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Smarter kernel modules?
The patch that I posted here can't possibly work, but there are other ways to deal. I'm investigating. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Smarter kernel modules?
On Thu, Mar 06, 2003 at 09:41:04AM -0700, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Peter Jeremy [EMAIL PROTECTED] writes: : Disadvantages: : - Needs grunt-work to write the #defines : - Kernel symbols reported by nm(1) look strange (unless we patch : binutils to understand our versioning scheme). : - May present problems to '##' built symbols. History has shown that people suck at keeping such a complex scheme up to date. Also, it versions functions, but not datta structures. Data strucutre changes are the number 1 cause of ABI breakage we've had over the last 5 years. I had thought it was fairly simple to maintain, but hadn't really thought through the issue of data structures. If a function or variable definition changes directly, it isn't a great deal of overhead to increment a number elsewhere in a header file that you have to edit anyway. (Though the number of 'bump PORTREVISION please' followups to ports commits suggests that it would be forgotten). If a struct/union/typedef changes, you would need to look through all the references to that type and update them. And if any of the references were another struct/union/typedef, you need to repeat the process. This would be onerous - especially for common types - and therefore neglected. I can't think of any way to easily automate this so I'll withdraw my suggestion. That said, I feel that a single number (or variable name) is too coarse and the do I need to bump the version decision is too fuzzy. Unfortunately, I can't think of anything better that wouldn't incur an unacceptable maintenance overhead. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Smarter kernel modules?
In message: [EMAIL PROTECTED] Peter Jeremy [EMAIL PROTECTED] writes: : That said, I feel that a single number (or variable name) is too : coarse and the do I need to bump the version decision is too fuzzy. : Unfortunately, I can't think of anything better that wouldn't incur : an unacceptable maintenance overhead. I want the decision to bump it to be I can't make this change because it would cause me to have to bump this version. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Smarter kernel modules?
I'm not sure if this topic has ever been covered before or not. I couldn't find it in the list archives, but then I wasn't exactly sure how to search for it. Has anyone ever considered embedding some sort of identifier in kernel modules to keep them from being loaded with the wrong kernel? Back when I used Linux, they had this thing that embedded the kernel version in all the modules, thus preventing you from shooting yourself in the foot when booting a different kernel. After just experiencing two panics and then finally booting an older kernel, I was bit three times by our lack of something like this. First, acpi.ko blew up in my face before I decided it'd be wise to specify /boot/kernel.old/acpi.ko. Secondly, linux.ko exploded in my face with rc.conf's linux_enable=YES. Finally, my system exploded when X tried to load the DRI/DRM modules. After this, I'm wondering why there isn't some sort of system to keep this foot shooting from happening. Wouldn't it be wise to embed some sort of cksum into the kernel and then only allow modules with the same cksum to be loaded (unless the user really wants to)? -- Sean Kelly | PGP KeyID: D2E5E296 [EMAIL PROTECTED] | http://www.zombie.org pgp0.pgp Description: PGP signature
Re: Smarter kernel modules?
In message: [EMAIL PROTECTED] Sean Kelly [EMAIL PROTECTED] writes: : Has anyone ever considered embedding some sort of identifier in kernel : modules to keep them from being loaded with the wrong kernel? Actually, I was talking about this with Matt Dodd this morning... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Smarter kernel modules?
Here's a simple patch. However, it is a total suck-ass kludge (and
that's being generous). The ABI isn't THE ABI, but rather a
collection of ABIs. These ABIs change slowly and there is a certain
range that work together. Historically, we've been really bad about
bumping version numbers when things change in modules. Also, there's
no built-in versioning in the module names, which makes it harder to
have multiple versions around. As such, the version numbers are set
to 1 and never change.
Warner
Index: sys/module.h
===
RCS file: /home/ncvs/src/sys/sys/module.h,v
retrieving revision 1.20
diff -u -r1.20 module.h
--- sys/module.h18 Mar 2002 07:45:30 - 1.20
+++ sys/module.h6 Mar 2003 04:51:04 -
@@ -95,7 +95,10 @@
#include sys/linker_set.h
+extern char __version_5_1;
+
#defineMODULE_METADATA(uniquifier, type, data, cval) \
+ static char *_mod_version_depend##uniquifier = __version_5_1; \
static struct mod_metadata _mod_metadata##uniquifier = {\
MDT_STRUCT_VERSION, \
type, \
Index: kern/kern_module.c
===
RCS file: /home/ncvs/src/sys/kern/kern_module.c,v
retrieving revision 1.41
diff -u -r1.41 kern_module.c
--- kern/kern_module.c 19 Feb 2003 05:47:25 - 1.41
+++ kern/kern_module.c 6 Mar 2003 04:51:04 -
@@ -42,6 +42,12 @@
static MALLOC_DEFINE(M_MODULE, module, module data structures);
+/*
+ * Define the version. Change the symbol name when things get too
+ * incompatible. version_5_1 means the 'ABI compatible with FreeBSD 5.1'
+ */
+char __version_5_1 = 1;
+
typedef TAILQ_HEAD(, module) modulelist_t;
struct module {
TAILQ_ENTRY(module) link; /* chain together all modules */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Smarter kernel modules?
At 2003-03-06T03:08:52Z, Sean Kelly [EMAIL PROTECTED] writes: Has anyone ever considered embedding some sort of identifier in kernel modules to keep them from being loaded with the wrong kernel? Unless I'm mistaken, 5.0 supports having multiple kernels installed, each with their own modules directories, under /boot. -- Kirk Strauser In Googlis non est, ergo non est. pgp0.pgp Description: PGP signature
Re: Smarter kernel modules?
On Wed, Mar 05, 2003 at 11:33:31PM -0600, Kirk Strauser wrote: At 2003-03-06T03:08:52Z, Sean Kelly [EMAIL PROTECTED] writes: Has anyone ever considered embedding some sort of identifier in kernel modules to keep them from being loaded with the wrong kernel? Unless I'm mistaken, 5.0 supports having multiple kernels installed, each with their own modules directories, under /boot. Yes, but this doesn't resolve the versioning issue. 1) If you update any of those kernels, the updated kernel and updated modules will be written into /boot/FOO/ as appropriate. BUT old modules that weren't rebuilt (eg 3rd party modules) will remain in /boot/FOO/. If the new kernel happened to change an API, you're likely to get a panic when you load the old module. 2) -CURRENT apparently looks in /modules/ as well as /boot/kernel/ - and any module found in the former is probably 4.x which will cause things to fail spectacularly. Versioning is the only way to solve both these problems. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Smarter kernel modules?
On Wed, Mar 05, 2003 at 09:59:01PM -0700, M. Warner Losh wrote: Here's a simple patch. However, it is a total suck-ass kludge (and that's being generous). The ABI isn't THE ABI, but rather a collection of ABIs. These ABIs change slowly and there is a certain range that work together. Historically, we've been really bad about bumping version numbers when things change in modules. Also, there's no built-in versioning in the module names, which makes it harder to have multiple versions around. As such, the version numbers are set to 1 and never change. My kernel coding skills are severely limited, so please adjust any pointing and laughing as appropriate. ... +/* + * Define the version. Change the symbol name when things get too + * incompatible. version_5_1 means the 'ABI compatible with FreeBSD 5.1' + */ +char __version_5_1 = 1; ... Wouldn't it make more sense to have a symbol name that doesn't change across versions? Something like '_module_version' perhaps. Then the value of the symbol is the version which the module corresponds to. This would let you use something like kern.osreldate or a per-subsystem version index. This would also save you from having to search through files that say _version_5_1 and instead just define '_module_version' using a #define in one of your headers. config.h: #define API_VERSION 500100 mymodule.c: long _module_version = API_VERSION; Another benefit(?) is that if _module_version is missing, you can decide that you don't care about versioning and just load the module. This could be useful for third-party modules that don't want to lock them down to a specific kernel/API/subsystem version. Not recommended, but optional. -- Sean Kelly | PGP KeyID: D2E5E296 [EMAIL PROTECTED] | http://www.zombie.org pgp0.pgp Description: PGP signature
Re: Smarter kernel modules?
On Wed, Mar 05, 2003 at 09:59:01PM -0700, M. Warner Losh wrote: Here's a simple patch. However, it is a total suck-ass kludge (and that's being generous). The ABI isn't THE ABI, but rather a collection of ABIs. These ABIs change slowly and there is a certain range that work together. I think you're being overly harsh. It strikes me as a very simple way to provide at least a coarse level of versioning. (The other downside is that the error messages may be too cryptic for a non-developer to understand). The biggest downside is that (as you point out) it is a single magic number to represent the version of all of the kernel interfaces. What you really want is a version number associated with each interface - then only modules that use that particular interface are affected. As for actually implementing this: How about a combination of C++ name-mangling and namespace.h from our libc? Change all our external kernel symbols so that foo shows up as foo__N (where N starts at 1 and increments every time something about foo's definition changes). Near the top of the include file containing the symbol declaration you add a #define foo foo__N so code doesn't see the version number. Benefits: - Versioning tied to specific symbol definition - no need to have a coarse bump the version when things get too incompatible. You can bump the version of a symbol when it changes at all. - Only modules that actually reference a changed symbol fail. - Versioning uses exact matches so the version number could go backwards if an API change gets backed out (eg the recent malloc M_WAITOK changes) - old modules would start to work again. Of course you've got to remember to skip that number on the next increment. - Automatically detects naughty code that doesn't include the appropriate headers. - The kernel's dynamic loader could be taught to provide legible error messages (eg foo.ko: Needs malloc version 123 found 126) - Potentially, shim modules could be created to supply legacy interfaces - at least for functions. (eg for the aborted malloc() changes, a shim function could have mapped between the different flags meanings). The kernel loader could even automatically look for shim .ko's. Disadvantages: - Needs grunt-work to write the #defines - Kernel symbols reported by nm(1) look strange (unless we patch binutils to understand our versioning scheme). - May present problems to '##' built symbols. Comments? Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
