According to Garrett Wollman:
> It's listening on a kernel notification socket. (Implementation is an
> exercise left for the reader, but there are already a few examples.)
Like the routing socket I guess ?
Or we could implement POLLSYSCTL ? :-)
/me hides and runs
--
Ollivier ROBERT -=- Free
"Jordan K. Hubbard" wrote:
>
> > In other words, it's not a problem specific to KLD's .. but
> > it's still a problem :-)
>
> Which raises an important issue - other than walking the sysctl tree
> regularly looking for changes, how does such an application become
> aware that the sysctl space h
In message <[EMAIL PROTECTED]>, Jul
ian Elischer writes:
[sysctlfs]
>Linux have basically done this in their procfs.
And have recently started to wonder if that wasn't a mistake I've heard.
I would regard sysctlfs as a grave mistake.
--
Poul-Henning Kamp FreeBSD coreteam member
[E
On Sat, 11 Dec 1999, Julian Elischer wrote:
> Linux have basically done this in their procfs.
If we're looking for a gross hack, we need look no further :-)
Kris
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Linux have basically done this in their procfs.
On Sat, 11 Dec 1999, Jordan K. Hubbard wrote:
> > Use a similar hack: map the sysctl tree to the filesystem (ala kernfs) and
> > then stat the directory nodes.
>
> AAIEE! sysctlfs!! :-)
>
> It's an interesting idea and I'm not sure why it a
"Jordan K. Hubbard" wrote:
>
> > In other words, it's not a problem specific to KLD's .. but
> > it's still a problem :-)
>
> Which raises an important issue - other than walking the sysctl tree
> regularly looking for changes, how does such an application become
> aware that the sysctl space h
< said:
> Which raises an important issue - other than walking the sysctl tree
> regularly looking for changes, how does such an application become
> aware that the sysctl space has changed?
It's listening on a kernel notification socket. (Implementation is an
exercise left for the reader, but
> Use a similar hack: map the sysctl tree to the filesystem (ala kernfs) and
> then stat the directory nodes.
AAIEE! sysctlfs!! :-)
It's an interesting idea and I'm not sure why it also horrifies me at
some inner, almost cellular, level. If somebody's actually willing to
do the work of cre
> Perhaps a modtime on the sysctl tree as a gross hack? Inside of sysctl() and
> the SYSCTL() macros you would update the time every time a write was made, no
de
> added, node removed, etc. However, it is a gross hack.
You're right, it would be a gross hack. :) Also, I can see where it
would b
> other than walking the sysctl tree regularly looking for changes
Use a similar hack: map the sysctl tree to the filesystem (ala kernfs) and
then stat the directory nodes.
John
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On 11-Dec-99 Jordan K. Hubbard wrote:
>> In other words, it's not a problem specific to KLD's .. but
>> it's still a problem :-)
>
> Which raises an important issue - other than walking the sysctl tree
> regularly looking for changes, how does such an application become
> aware that the sysctl
> In other words, it's not a problem specific to KLD's .. but
> it's still a problem :-)
Which raises an important issue - other than walking the sysctl tree
regularly looking for changes, how does such an application become
aware that the sysctl space has changed? The same holds true for a
dyn
Jordan K. Hubbard writes:
> > I think the latter. In 'theory' there should be no discernable
> > difference between functionality from a KLD vs. the same functionality
> > compiled directly into the kernel.
>
> Only in theory, of course. :)
>
> As Andrzej has already pointed out, modules can als
> I think the latter. In 'theory' there should be no discernable
> difference between functionality from a KLD vs. the same functionality
> compiled directly into the kernel.
Only in theory, of course. :)
As Andrzej has already pointed out, modules can also be loaded and
unloaded, creating a sys
Andrzej Bialecki writes:
> > KLD's are just a linking mechanism, and shouldn't have any more
> > significance than that from a usability perspective.
>
> Hah. If it were so simple...
>
> Let's take the example of a module foo, which provides unique features of
> bar and baz. They are unrelated t
On Thu, 9 Dec 1999, Archie Cobbs wrote:
> Andrzej Bialecki writes:
> > I'd like to know whether we reached some conclusions concerning the naming
> > of sysctl variables created (or related to) KLDs. I know that Linux
> > emulator creates "compat.linux". I don't know if any other module creates
>
Andrzej Bialecki writes:
> I'd like to know whether we reached some conclusions concerning the naming
> of sysctl variables created (or related to) KLDs. I know that Linux
> emulator creates "compat.linux". I don't know if any other module creates
> sysctls (well, except my SPY module.. :-).
>
>
Hi,
I'd like to know whether we reached some conclusions concerning the naming
of sysctl variables created (or related to) KLDs. I know that Linux
emulator creates "compat.linux". I don't know if any other module creates
sysctls (well, except my SPY module.. :-).
So, what is the current thinking
18 matches
Mail list logo
