;
> >> 23:31:33 +0930):
> >> > Content-Type: text/plain;
> >> > charset="utf-8"
> >> > Content-Transfer-Encoding: quoted-printable
> >> > Content-Disposition: inline
> >> >
> >> > Is it possible? the handbook implies
g: quoted-printable
> Content-Disposition: inline
>
> Is it possible? the handbook implies not and I can't get it to
> work, but i could be doing it wrong..
>
> I get fbt traces listed for KLDs (I get new entries for each load
> of the KLD which seems like a potential problem) but I
t wrong..
I get fbt traces listed for KLDs (I get new entries for each load of the
KLD which seems like a potential problem) but I can't specify an
SDT_PROBE and have it work.
Can you show us some example code?
In
http://svn.freebsd.org/viewvc/base/user/netchild/linuxulator-dt
inline
> >
> > Is it possible? the handbook implies not and I can't get it to
> > work, but i could be doing it wrong..
> >
> > I get fbt traces listed for KLDs (I get new entries for each load
> > of the KLD which seems like a potential problem) but I can
Is it possible? the handbook implies not and I can't get it to work, but
i could be doing it wrong..
I get fbt traces listed for KLDs (I get new entries for each load of the
KLD which seems like a potential problem) but I can't specify an
SDT_PROBE and have it work.
--
Danie
It appears that the KLD build process is missing a ctfmerge at the end, and
this results in KLDs with incomplete CTF information.
Here is a patch that fixes this. I verified it on amd64 with various KLDs.
Before:
# ctfdump /boot/kernel/if_cxgb.ko | wc -l
2269
# ctfdump /boot/kernel/zfs.ko | wc
On Tue, 30 Nov 2004 15:58, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
>
> "Daniel O'Connor" <[EMAIL PROTECTED]> writes:
> : On Tue, 30 Nov 2004 14:35, M. Warner Losh wrote:
> : > Can't you just add modules override with absolute path name?
> :
> : I don't think so, because.
In message: <[EMAIL PROTECTED]>
"Daniel O'Connor" <[EMAIL PROTECTED]> writes:
: On Tue, 30 Nov 2004 14:35, M. Warner Losh wrote:
: > Can't you just add modules override with absolute path name?
:
: I don't think so, because..
MODULES_OVERRIDE is different. It can take a list of paths
On Tue, 30 Nov 2004 14:35, M. Warner Losh wrote:
> Can't you just add modules override with absolute path name?
I don't think so, because..
On Mon, 29 Nov 2004 23:08, Ruslan Ermilov wrote:
> Any chance you can use the recently added PORTS_MODULES knob to do what
> you want?
Hmm.. I don't really
Can't you just add modules override with absolute path name?
Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
On Mon, 29 Nov 2004 23:08, Ruslan Ermilov wrote:
> > Note that (obviously) the ports need to be tweaked to install the driver
> > source and build infrastructure there, but that's not too hard (to do by
> > hand for now anyway). I have the 4 I mentioned building just fine with 5
> > minutes work.
>
On Mon, Nov 29, 2004 at 10:54:26PM +1030, Daniel O'Connor wrote:
> Hi,
> I have a few "third party" KLDs on my system (nvidia, acpi_ppc, dell,
> if_ndis)
> and it's quite annoying to have to rebuild them each kernel build, or
> upgrade. I have thought about
Hi,
I have a few "third party" KLDs on my system (nvidia, acpi_ppc, dell, if_ndis)
and it's quite annoying to have to rebuild them each kernel build, or
upgrade. I have thought about putting them in /boot/modules but I have had
this crash on my fairly often (esp since I am r
Can somebody explain to me how sysctls from klds are relocated?
For background, after the binutils upgrade in -stable, I'm unable to
load linux.ko on my desktop. The faulting address is always
0x9010102464c457f (oidp->oid_parent) and the pc is in
sysctl_find_oid_name().
The crash lo
I use them - where possible - when i have the same kernel for different boxes
and i can configure the differences via klm's.
danny
> Hi Folks,
>
> Hopefully a quick question.
>
> Is there any reason to prefer KLD modules for drivers etc over static
> linking? For exam
Hi Folks,
Hopefully a quick question.
Is there any reason to prefer KLD modules for drivers etc over static
linking? For example, KLDs are covenient, loading and unloading for
development but is it a case of using KLD modules for development then
building drivers statically into the kernel when
how to
> call the probe and attach calls during the load for a PCI device. I have
> looked in the /usr/src/sys/pci directory and haven't found any KLDs to use
> as an example. What are the steps I need to take to handle a PCI device in
> a KLD? Are there any examples I can look
In message <[EMAIL PROTECTED]> "Chris Ptacek"
writes:
: I am working on a KLD for a PCI device. My problem is I can't find how to
: call the probe and attach calls during the load for a PCI device. I have
: looked in the /usr/src/sys/pci directory and haven't fou
> I am working on a KLD for a PCI device. My problem is I can't find how to
> call the probe and attach calls during the load for a PCI device. I have
> looked in the /usr/src/sys/pci directory and haven't found any KLDs to use
> as an example. What are the steps I need t
I am working on a KLD for a PCI device. My problem is I can't find how to
call the probe and attach calls during the load for a PCI device. I have
looked in the /usr/src/sys/pci directory and haven't found any KLDs to use
as an example. What are the steps I need to take to handle a
Mike Smith writes:
> > I expect as much, but when I tried to make an IPX KLD, it paniced the
> > system on unload. I will test the FFS KLD soon though.
>
> Panic on unload usually means that the code in question isn't designed
> to unload. 8)
Such code should return an error instead of allowi
> On Mon, 18 Oct 1999, Mike Smith wrote:
>
> > > Is it possible to compile a kernel with no filesystems supported and have
> > > the boot loader load FFS? I have built an FFS module but I have not yet
> > > had time to test it. Frankly, I am kind of afraid to for fear of trashing
> > > my syste
On Mon, 18 Oct 1999, Mike Smith wrote:
> > Is it possible to compile a kernel with no filesystems supported and have
> > the boot loader load FFS? I have built an FFS module but I have not yet
> > had time to test it. Frankly, I am kind of afraid to for fear of trashing
> > my system.
>
> As l
> Is it possible to compile a kernel with no filesystems supported and have
> the boot loader load FFS? I have built an FFS module but I have not yet
> had time to test it. Frankly, I am kind of afraid to for fear of trashing
> my system.
As long as the kernel will compile with no filesystems,
On Tue, 12 Oct 1999, Warner Losh wrote:
>
> How does one tell ddb about dynamic modules? I've had a couple of
> crashes in my code where I've needed symbols from things dynamically
> loaded... Does gdb grok them any better?
>
I thought ddb was supposed to know about them already but perhaps
How does one tell ddb about dynamic modules? I've had a couple of
crashes in my code where I've needed symbols from things dynamically
loaded... Does gdb grok them any better?
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
On Sun, 10 Oct 1999, Mike Smith wrote:
> You should note that neither QNX nor FreeBSD exhibit the above
> behaviour. KLD is a linker; it allows you to link more stuff into the
> kernel after it's been started. It doesn't implement a coprocess model
> of any sort.
Yes, I knew this for FreeBS
> > Could things be done in such a way that like QNX, it can
> > kill and restart a misbehaving driver? What other cool things can be
> > done?
>
> QNX doesn't do that.
> Actually, in many cases it does. There are numerous advantages in a
> well-designed/optimized micro-kernel that FreeBSD wi
> > Could things be done in such a way that like QNX, it can
> > kill and restart a misbehaving driver? What other cool things can be
> > done?
>
> QNX doesn't do that.
Actually, in many cases it does. There are numerous advantages in a
well-designed/optimized micro-kernel that FreeBSD will n
> On Slashdot, in a discussion regarding QNX, someone described it with the
> following:
>
> Under QNX, if your driver crashes, the kernel just restarts it.
>
> After reading it, I became more interested in KLDs. My only prior
> experiece was installing the Linux
On Sat, 9 Oct 1999, W Gerald Hicks wrote:
> > On Slashdot, ...
> >
> > Under QNX, if your driver crashes, the kernel just restarts it.
>
> That's not in the least bit how QNX works... oh well, it's slashdot.
I've noticed Slashdotters tend to be clueless.
It doesn't matter in this case,
> On Slashdot, ...
>
> Under QNX, if your driver crashes, the kernel just restarts it.
That's not in the least bit how QNX works... oh well, it's slashdot.
Cheers,
Jerry Hicks
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the bo
On Slashdot, in a discussion regarding QNX, someone described it with the
following:
Under QNX, if your driver crashes, the kernel just restarts it.
After reading it, I became more interested in KLDs. My only prior
experiece was installing the Linux KLD and that was done by a port
> Juha Nurmela wrote:
> >
> >
> > On Tue, 3 Aug 1999, Daniel C. Sobral wrote:
> >
> > > Actually... Loader passes a string. It seems the kldcode is passing
> > > argv[]. Juha, you sure you have they both working the same way (from
> > > a module's perspective)?
> >
> > It's splatted together, b
On Tue, 3 Aug 1999, Peter Wemm wrote:
> Don't forget, there are zero or more modules per file. Which one gets the
> arguments? Coda (for example) is structured so that it has two modules, one
> device (codadev) and one vfs (coda).
Yes, the naming 'module_get_file_argstr()' had the _file_ for
> Juha Nurmela wrote:
> >
> >
> > On Tue, 3 Aug 1999, Daniel C. Sobral wrote:
> >
> > > Actually... Loader passes a string. It seems the kldcode is passing
> > > argv[]. Juha, you sure you have they both working the same way (from
> > > a module's perspective)?
> >
> > It's splatted together,
"Daniel C. Sobral" wrote:
> Peter Wemm wrote:
> >
> > Don't forget, there are zero or more modules per file. Which one gets the
> > arguments? Coda (for example) is structured so that it has two modules, on
e
> > device (codadev) and one vfs (coda).
>
> It seems to me that the one who gets
On Tue, 3 Aug 1999, Peter Wemm wrote:
> Don't forget, there are zero or more modules per file. Which one gets the
> arguments? Coda (for example) is structured so that it has two modules, one
> device (codadev) and one vfs (coda).
Yes, the naming 'module_get_file_argstr()' had the _file_ for
Peter Wemm wrote:
>
> Don't forget, there are zero or more modules per file. Which one gets the
> arguments? Coda (for example) is structured so that it has two modules, one
> device (codadev) and one vfs (coda).
It seems to me that the one who gets the arguments is the one who
searches for it.
Juha Nurmela wrote:
>
>
> On Tue, 3 Aug 1999, Daniel C. Sobral wrote:
>
> > Actually... Loader passes a string. It seems the kldcode is passing
> > argv[]. Juha, you sure you have they both working the same way (from
> > a module's perspective)?
>
> It's splatted together, by just putting ' ' b
"Daniel C. Sobral" wrote:
>
> assuming we are making it at all, the less pain. It provides a way
> of getting parameters that is compatible with what is already
> possible with loader (ie, the module need not differentiate between
> it's method of loading). The code is working and ready.
Actuall
On Tue, 3 Aug 1999, Daniel C. Sobral wrote:
> Actually... Loader passes a string. It seems the kldcode is passing
> argv[]. Juha, you sure you have they both working the same way (from
> a module's perspective)?
It's splatted together, by just putting ' ' between words,
somewhere in there. Sea
"Daniel C. Sobral" wrote:
> Peter Wemm wrote:
> >
> > Don't forget, there are zero or more modules per file. Which one gets the
> > arguments? Coda (for example) is structured so that it has two modules, on
e
> > device (codadev) and one vfs (coda).
>
> It seems to me that the one who gets
Peter Wemm wrote:
>
> Don't forget, there are zero or more modules per file. Which one gets the
> arguments? Coda (for example) is structured so that it has two modules, one
> device (codadev) and one vfs (coda).
It seems to me that the one who gets the arguments is the one who
searches for it
On Tue, 3 Aug 1999, Daniel C. Sobral wrote:
> Actually... Loader passes a string. It seems the kldcode is passing
> argv[]. Juha, you sure you have they both working the same way (from
> a module's perspective)?
It's splatted together, by just putting ' ' between words,
somewhere in there. Sear
Juha Nurmela wrote:
>
>
> On Tue, 3 Aug 1999, Daniel C. Sobral wrote:
>
> > Actually... Loader passes a string. It seems the kldcode is passing
> > argv[]. Juha, you sure you have they both working the same way (from
> > a module's perspective)?
>
> It's splatted together, by just putting ' '
"Daniel C. Sobral" wrote:
>
> assuming we are making it at all, the less pain. It provides a way
> of getting parameters that is compatible with what is already
> possible with loader (ie, the module need not differentiate between
> it's method of loading). The code is working and ready.
Actually
On Tue, 3 Aug 1999, Daniel C. Sobral wrote:
> Warner Losh wrote:
> >
> > In message <37a5c680.3ca1d...@newsguy.com> "Daniel C. Sobral" writes:
> > : Modules are not just drivers. Forget about drivers, and try again.
> > : :-)
> >
> > But the generic mechanism extends beyond just drivers :-)
>
>
On Tue, 3 Aug 1999, Daniel C. Sobral wrote:
> Warner Losh wrote:
> >
> > In message <[EMAIL PROTECTED]> "Daniel C. Sobral" writes:
> > : Modules are not just drivers. Forget about drivers, and try again.
> > : :-)
> >
> > But the generic mechanism extends beyond just drivers :-)
>
> Ah, I reca
Warner Losh wrote:
>
> In message <37a5c680.3ca1d...@newsguy.com> "Daniel C. Sobral" writes:
> : Modules are not just drivers. Forget about drivers, and try again.
> : :-)
>
> But the generic mechanism extends beyond just drivers :-)
Ah, I recall now. Something similar to the way X works, with a
In message <37a5c680.3ca1d...@newsguy.com> "Daniel C. Sobral" writes:
: Modules are not just drivers. Forget about drivers, and try again.
: :-)
But the generic mechanism extends beyond just drivers :-)
Warner
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers"
Warner Losh wrote:
>
> In message <[EMAIL PROTECTED]> "Daniel C. Sobral" writes:
> : Modules are not just drivers. Forget about drivers, and try again.
> : :-)
>
> But the generic mechanism extends beyond just drivers :-)
Ah, I recall now. Something similar to the way X works, with all the
info
Warner Losh wrote:
>
> In message
> Juha Nurmela writes:
> : Yes, but (this might be a trademark ;) commonly the arguments would
> : be used during the sysinit->attach, and at that time sysctl has not yet
> : been able to change anything. Use of sysctl would require a sidestep
> : from attach an
In message <[EMAIL PROTECTED]> "Daniel C. Sobral" writes:
: Modules are not just drivers. Forget about drivers, and try again.
: :-)
But the generic mechanism extends beyond just drivers :-)
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of
Warner Losh wrote:
>
> In message <[EMAIL PROTECTED]> Juha
>Nurmela writes:
> : Yes, but (this might be a trademark ;) commonly the arguments would
> : be used during the sysinit->attach, and at that time sysctl has not yet
> : been able to change anything. Use of sysctl would require a sidestep
On Sun, 1 Aug 1999, Chris Costello wrote:
> On Sun, Aug 01, 1999, Juha Nurmela wrote:
> >
> > Sometimes it would be handy to pass a commandline
> > to a kld, preloaded modules already support
> > arguments. kldload(2) unfortunately has only
> > the pathname.ko argument.
>
>Is this really a pr
On Sun, 1 Aug 1999, Chris Costello wrote:
> On Sun, Aug 01, 1999, Juha Nurmela wrote:
> >
> > Sometimes it would be handy to pass a commandline
> > to a kld, preloaded modules already support
> > arguments. kldload(2) unfortunately has only
> > the pathname.ko argument.
>
>Is this really a p
In message Juha
Nurmela writes:
: Yes, but (this might be a trademark ;) commonly the arguments would
: be used during the sysinit->attach, and at that time sysctl has not yet
: been able to change anything. Use of sysctl would require a sidestep
: from attach and later continuation with a sysctl
In message <[EMAIL PROTECTED]> Juha Nurmela
writes:
: Yes, but (this might be a trademark ;) commonly the arguments would
: be used during the sysinit->attach, and at that time sysctl has not yet
: been able to change anything. Use of sysctl would require a sidestep
: from attach and later contin
On Sun, 1 Aug 1999, Chris Costello wrote:
> On Sun, Aug 01, 1999, Juha Nurmela wrote:
> > Sometimes it would be handy to pass a commandline
> > to a kld, preloaded modules already support
> > arguments. kldload(2) unfortunately has only
> > the pathname.ko argument.
>
>Is this really a prob
On Sun, Aug 01, 1999, Juha Nurmela wrote:
>
> Hello.
>
> Sometimes it would be handy to pass a commandline
> to a kld, preloaded modules already support
> arguments. kldload(2) unfortunately has only
> the pathname.ko argument.
Is this really a problem? Can the administrator not use
sysctl i
On Sun, 1 Aug 1999, Chris Costello wrote:
> On Sun, Aug 01, 1999, Juha Nurmela wrote:
> > Sometimes it would be handy to pass a commandline
> > to a kld, preloaded modules already support
> > arguments. kldload(2) unfortunately has only
> > the pathname.ko argument.
>
>Is this really a pro
On Sun, Aug 01, 1999, Juha Nurmela wrote:
>
> Hello.
>
> Sometimes it would be handy to pass a commandline
> to a kld, preloaded modules already support
> arguments. kldload(2) unfortunately has only
> the pathname.ko argument.
Is this really a problem? Can the administrator not use
sysctl
Hello.
Sometimes it would be handy to pass a commandline
to a kld, preloaded modules already support
arguments. kldload(2) unfortunately has only
the pathname.ko argument.
Following url proposes patches to make a new syscall
kldload(char *pathname, char **argv, struct kldload *)
and keep old way
Hello.
Sometimes it would be handy to pass a commandline
to a kld, preloaded modules already support
arguments. kldload(2) unfortunately has only
the pathname.ko argument.
Following url proposes patches to make a new syscall
kldload(char *pathname, char **argv, struct kldload *)
and keep old wa
65 matches
Mail list logo
