This patch adds ident daemon to net/gnuidentd/
directory.
Apply to: 2.6.15.1.
Patch is here:
http://unwd.sourceforge.net/gnuidentd-2.6.15.patch
I used two threads: one for connections handling and
another for tracking /etc/passwd changes through
inotify.
Additionally, root can set users hiding rules using
file in /proc.
I'm awaiting your notes/tips.
Please CC me to <[email protected]>
Signed-Off-by: Edward Chernenko <[email protected]>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
>This patch adds ident daemon to net/gnuidentd/
>directory.
>Apply to: 2.6.15.1.
>Patch is here:
>http://unwd.sourceforge.net/gnuidentd-2.6.15.patch
>
>I used two threads: one for connections handling and
>another for tracking /etc/passwd changes through
>inotify.
>Additionally, root can set users hiding rules using
>file in /proc.
>
>I'm awaiting your notes/tips.
I dislike this concept. khttpd once tried the same (moving
userspace to kernelspace) -- and it's out again.
Jan Engelhardt
--
2006/3/25, Jan Engelhardt <[email protected]>:
>
> I dislike this concept. khttpd once tried the same
(moving
> userspace to kernelspace) -- and it's out again.
>
Comparing with khttpd, we have no need to make
transfers between
userspace and kernelspace; additionally, ident daemon
depends on
kernel connections table. This is very efficient to
avoid using proc
interface by userspace program here.
--
Edward Chernenko <[email protected]>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
> Comparing with khttpd, we have no need to make
> transfers between userspace and kernelspace;
For any of this to be motivating to anyone here, you'll have to
present an argument as to why this can't be done in userspace. identd
isn't a terribly complex thing -- one would think that a carefully
crafted userspace daemon could saturate any reasonable network
connection.
Conversely, if it can't be done fast from userspace, then people to
hear about that. That means that there's some task the kernel needs to
be made more faster at doing.
And if whatever potential performance problems with the kernel are
fixed, then all applications, including your userspace identd too,
will benefit from the fixes.
>>This patch adds ident daemon to net/gnuidentd/
>>directory.
>>Apply to: 2.6.15.1.
>>Patch is here:
>>http://unwd.sourceforge.net/gnuidentd-2.6.15.patch
>>
>>I used two threads: one for connections handling and
>>another for tracking /etc/passwd changes through
>>inotify.
>>Additionally, root can set users hiding rules using
>>file in /proc.
>>
>>I'm awaiting your notes/tips.
Are you even allowed to use the name "GNU identd"?
I'm not seeing your identd listed on GNU.org, that is, having
a page at http://www.gnu.org/software/identd/ like e.g. GRUB does.
Jan Engelhardt
--
--- Jan Engelhardt <[email protected]> wrote:
>
> Are you even allowed to use the name "GNU identd"?
> I'm not seeing your identd listed on GNU.org, that
> is, having
> a page at http://www.gnu.org/software/identd/ like
> e.g. GRUB does.
>
Only portable (but not Linux-specific) software coud
be placed in gnu.org, if you don't know.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
On Fri, 2006-03-24 at 08:21 -0800, Edward Chernenko wrote:
> This patch adds ident daemon to net/gnuidentd/
> directory.
> Apply to: 2.6.15.1.
> Patch is here:
> http://unwd.sourceforge.net/gnuidentd-2.6.15.patch
>
> I used two threads: one for connections handling and
> another for tracking /etc/passwd changes through
> inotify.
> Additionally, root can set users hiding rules using
> file in /proc.
>
> I'm awaiting your notes/tips.
> Please CC me to <[email protected]>
>
> Signed-Off-by: Edward Chernenko <[email protected]>
Justification, please.
You haven't even tried to explain to us what is so broken about the
userland identd that it needs to be replaced with a kernel version.
Cheers,
Trond
Edward Chernenko <[email protected]> wrote:
>
> Comparing with khttpd, we have no need to make
> transfers between
> userspace and kernelspace; additionally, ident daemon
> depends on
> kernel connections table. This is very efficient to
> avoid using proc
> interface by userspace program here.
Check out the pidentd in Debian. It uses netlink instead of procfs which
is much more scalable.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--- Trond Myklebust <[email protected]>
wrote:
>
> Justification, please.
>
> You haven't even tried to explain to us what is so
> broken about the
> userland identd that it needs to be replaced with a
> kernel version.
>
My point is that everything which follows this
conditions should be moved into kernel:
- must dispatch requests in a fixed time
- must work rarely, sleep most time
- must depend on internal kernel variables (for
example, established connections table)
Don't forget that many years ago there was echo daemon
in userspace. But as it's highly effective to dispatch
all echo requests in kernel, it was moved into
low-level TCP implementation.
I think that ident protocol also matches this
criteria.
Edward Chernenko <[email protected]>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
On Tue, 2006-03-28 at 02:14 -0800, Edward Chernenko wrote:
> --- Trond Myklebust <[email protected]>
> wrote:
> >
> > Justification, please.
> >
> > You haven't even tried to explain to us what is so
> > broken about the
> > userland identd that it needs to be replaced with a
> > kernel version.
> >
>
> My point is that everything which follows this
> conditions should be moved into kernel:
> - must dispatch requests in a fixed time
> - must work rarely, sleep most time
> - must depend on internal kernel variables (for
> example, established connections table)
>
> Don't forget that many years ago there was echo daemon
> in userspace. But as it's highly effective to dispatch
> all echo requests in kernel, it was moved into
> low-level TCP implementation.
>
> I think that ident protocol also matches this
> criteria.
Most servers are designed for low latency. A lot of them sleep a lot,
and a fair number of them also go poking around the kernel variables
in /proc (which exists precisely in order to export internal kernel
variables to userspace programs). I'll bet even your average Oracle
database application fits those criteria.
Echo made sense to move into the kernel because in addition to the above
it is a required feature on all Internet hosts, is pretty much stateless
(and/or depends only on internal IP stack state), and needs extra low
latency because it is designed to be used for timing purposes by
clients.
The same criteria hardly apply to identd.
Cheers,
Trond
--- Trond Myklebust <[email protected]>
wrote:
> Most servers are designed for low latency. A lot of
> them sleep a lot,
> and a fair number of them also go poking around the
> kernel variables
> in /proc (which exists precisely in order to export
> internal kernel
> variables to userspace programs). I'll bet even your
> average Oracle
> database application fits those criteria.
>
> Echo made sense to move into the kernel because in
> addition to the above
> it is a required feature on all Internet hosts, is
> pretty much stateless
> (and/or depends only on internal IP stack state),
> and needs extra low
> latency because it is designed to be used for timing
> purposes by
> clients.
> The same criteria hardly apply to identd.
If so, then why khttpd _was_ included into kernel?
Edward Chernenko <[email protected]>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
On Tue, 2006-03-28 at 07:48 -0800, Edward Chernenko wrote:
>
> --- Trond Myklebust <[email protected]>
> wrote:
>
> > Most servers are designed for low latency. A lot of
> > them sleep a lot,
> > and a fair number of them also go poking around the
> > kernel variables
> > in /proc (which exists precisely in order to export
> > internal kernel
> > variables to userspace programs). I'll bet even your
> > average Oracle
> > database application fits those criteria.
> >
> > Echo made sense to move into the kernel because in
> > addition to the above
> > it is a required feature on all Internet hosts, is
> > pretty much stateless
> > (and/or depends only on internal IP stack state),
> > and needs extra low
> > latency because it is designed to be used for timing
> > purposes by
> > clients.
> > The same criteria hardly apply to identd.
>
> If so, then why khttpd _was_ included into kernel?
That has been widely acknowledged as a mistake. You'll note that khttpd
was removed prior to the release of linux-2.6.0. Nobody misses it.
Cheers,
Trond
--- Trond Myklebust <[email protected]>
wrote:
> >
> > If so, then why khttpd _was_ included into kernel?
>
> That has been widely acknowledged as a mistake.
> You'll note that khttpd
> was removed prior to the release of linux-2.6.0.
> Nobody misses it.
>
That's bad. I think that some people need this, so my
module will be distributed like Tux webserver,
separately from kernel.
Anyway, can you help me by explaining your opinion
about my code, not about development phylosophy?
That's my first work and it's important to me to find
if I done something unefficient.
Edward Chernenko <[email protected]>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com