mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kyle Moffett <mrmacman_g4@mac.com>
To: "C. Scott Ananian" <cscott@laptop.org>
Cc: Arnd Bergmann <arnd@arndb.de>, linux-kernel@vger.kernel.org
Subject: Re: inotify and /proc?
Date: Sun, 24 Jun 2007 23:12:55 -0400	[thread overview]
Message-ID: <14E8CC97-77F3-4656-ACEC-324B92BE3067@mac.com> (raw)
In-Reply-To: <c6d9bea0706221551g2a50e5a1u56a11b1965fdd61d@mail.gmail.com>

On Jun 22, 2007, at 18:51:10, C. Scott Ananian wrote:
> Back to kernel-land: in an IPv6 only world, it might make sense to  
> export a /proc file compatible with the format of /etc/resolv.conf,  
> with one DNS server address per line.  If glibc uses/used inotify  
> on /etc/resolv.conf, then symlinking /etc/resolv.conf to /proc/net/ 
> ipv6_dns allows glibc to get kernel DNS autoconfiguration updates  
> without a special case.  [Assuming that glibc was smart enough to  
> watch the referenced file and not the symlink...]
>
> A draft patch to implement /proc/net/ipv6_dns is attached, just to  
> make the discussion concrete. [Not guaranteed to apply cleanly, as  
> I'm not sure that gmail won't munge the whitespace.  But it should  
> be readable at least.]

Ewwww, I suspect you're likely to get a lot of NAKs from people on  
this one.

1)  Why must the kernel grok the DNS portions of the packets?  Can't  
you just have a little userspace daemon which listens for the  
appropriate ICMPv6 messages and updates /etc/resolv.conf  
accordingly?  That way you could even have userspace policy about  
which DNS information is acceptable for the given system.

2)  New files in /proc which aren't directly related to processes are  
strictly forbidden.  Hopefully eventually (IE: in several years when  
appropriate replacements are widely used) the /proc/meminfo, /proc/ 
cpuinfo, /proc/mdstat, and other similar non-process-related files  
can be made to go away, but we certainly aren't adding new ones.

3)  It's really ugly to generate random text data from kernelspace,  
because then people write 42 different userspace parsers for the text  
data and each one has subtle incompatibilities which make it  
impossible to extend the file in the future.  This is why (2) is true.

4)  Within 30 sec of such a patch going in, the virtualization people  
are going to start griping at you for not properly implementing a  
virtual namespace-ized IPv6 DNS autoconfiguration proc-file.  Since  
that really can't be done easily without putting lots of policy in  
the kernel it's probably easier to just follow the advice in (1) and  
do it in userspace.

Cheers,
Kyle Moffett


      parent reply	other threads:[~2007-06-25  3:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-21 19:54 C. Scott Ananian
2007-06-21 23:17 ` Arnd Bergmann
2007-06-22 22:51   ` C. Scott Ananian
2007-06-22 23:28     ` Al Viro
2007-06-25  3:12     ` Kyle Moffett [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=14E8CC97-77F3-4656-ACEC-324B92BE3067@mac.com \
    --to=mrmacman_g4@mac.com \
    --cc=arnd@arndb.de \
    --cc=cscott@laptop.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®