lkml.org 
[lkml]   [2006]   [Jun]   [4]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateSun, 4 Jun 2006 20:10:36 -0700
From"Randy.Dunlap" <>
SubjectRe: utsname/hostname
On Sun, 4 Jun 2006 18:06:18 -0700 Andrew Morton wrote:

> On Sun, 4 Jun 2006 17:02:18 -0700
> "Randy.Dunlap" <rdunlap@xenotime.net> wrote:
> 
> > >  utsname virtualisation.  This doesn't seem very pointful as a standalone
> > >  thing.  That's a general problem with infrastructural work for a very
> > >  large new feature.
> > > 
> > >  So probably I'll continue to babysit these patches, unless someone can
> > >  identify a decent reason why mainline needs this work.
> > 
> > Not a strong argument for mainline, but I have a patch to make
> > <hostname> larger (up to 255 bytes, per POSIX).
> >   http://www.xenotime.net/linux/patches/hostname-2617-rc5b.patch
> 
> My immediate reaction to that was to tell posix to go take a hike.  I mean,
> sheesh.

well thanks for finally replying then.
That's my reaction to some other patches (in -mm) as well
(not that it matters).

> > I can either update my hostname patch against mm/utsname.. or not.
> > But I don't really want to see some/any patch blocked due to a patch
> > in -mm being borderline "pointful," so how do we deal with this?
> 
> Well first we need to work out if there's any vague reason why we need to
> mucky up our kernel by implementing this dopey spec.  If there is such a
> reason then I guess I drop all the ustname patches and ask that they be
> redone.  They're a bit straggly and a refactoring/rechanngelogging wouldn't
> hurt.

Fixing the changelog is easy.  What refactoring do you mean?

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
\
 
 \ /
  Last update: 2006-06-05 03:11    [from the cache]
©2003-2008