Hi,
I have provided a link to the built toolchain:
http://www.shakthimaan.com/downloads/hurd/root-gcc-4.1-glibc-2.7-toolchain.tar.bz2
(40 MB)
http://www.shakthimaan.com/downloads/hurd/root-gcc-4.2-glibc-2.7-toolchain.tar.bz2
(41 MB)
from here:
http://www.nongnu.org/hutos/
Is it possible for you
Hi Carl,
Thanks a lot in taking time to rgo through my proposal.
I think you've done a really great job of writing this proposal!
> There's not much to comment on really. :-)
Thanks
> The project thus aims at making the GNU/Linux process management
> > tools like ps, top, vmstat, sysctl, w, ki
Hi Carl,
> This is perhaps the root of the misunderstanding, we don't need to be
> ahead of linux when it comes to procfs. procfs should only provide a
> different interface to features /already/ present in the Hurd, i.e. a
> compatibility layer. Your desire to propel the Hurd beyond linux is
>
Hi Carl, Olaf and all,
>
>
> I didn't mean to say that /proc/*/mem is problematic per se. I rather
> meant that it's problematic to implement a Linux-compatible version in
> the Hurd procfs translator.
>
> The issue is that it's not possible to obtain all of the information
> listed by the Linux v
Hi,
On Fri, Mar 28, 2008 at 11:21:42AM +0100, Carl Fredrik Hammar wrote:
> It seems to me that many (most?) of the translators will be /very/
> simple. For uptime, cpuinfo, cmdline etc. their task boils down to
> gather some info and produce a string using with asprintf().
>
> This is much like
Hi,
On Fri, Mar 28, 2008 at 06:04:51PM -0600, Joshua Stratton wrote:
> Basically, I was thinking the network stack could be divided into
> different translators per protocol and give the client access to
> different layers based on his needs.
Indeed, that was not explicitely mentioned in the pro
Hi,
On Thu, Mar 27, 2008 at 05:50:37PM -0600, Joshua Stratton wrote:
> I'd still like some feedback from the Hurd developers about what they
> would like to see in the TCP/IP rewrite.
A bit of patience, please :-)
> From what I envision, it would be modular design of two or more
> translators (
Hi,
On Sat, Mar 29, 2008 at 08:40:30AM +0530, Madhusudan C.S wrote:
> I want to bring few points to your notice, though I had
> understood the need for GNU/Linux compatibility of the procfs
> that is to be implemented, I always felt that the GNU System
> should be always ahead
Hi,
On Thu, Mar 27, 2008 at 07:50:41PM +0530, Madhusudan C.S wrote:
> IpPI is nothing but a refinement of libnetfs or more clearly procfs
> specific libnetfs, in your terms libprocfs. This is done for two
> reasons,
>
> 1. To make the design robust, I dont want the effort who ever puts to
> go
Hi,
On Fri, Mar 28, 2008 at 03:34:20PM -0500, Manish Regmi wrote:
> I dont know if this is the right list for this question.
Yes it is :-)
If possible, you might also want to talk about this on IRC -- direct
communication is easier in such cases...
> I am quite unsure which project to choos
Hi,
I think you've done a really great job of writing this proposal!
There's not much to comment on really. :-)
"Madhusudan C.S" <[EMAIL PROTECTED]> writes:
> The project thus aims at making the GNU/Linux process management
> tools like ps, top, vmstat, sysctl, w, kill, skill, nice, snice,
> pgr
Hi Olaf, Carl and all,
I have submitted a totally reworked proposal through Google Web
App. This proposal reflects all the suggestions you have made previously. I
written my proposal so that it falls in line with the Hurd's requirements at
the moment as you people have told me. The same p
I thought a directory structure might be a more intuitive interface. It
doesn't matter too much to me, as long as it stays intuitive down the road.
I guess since it's really only going to implement two layers of the OSI
model, it doesn't matter. A list might be more accessible.
Thanks for the fe
Hi,
> Olaf made some comments on my proposal and wanted to know a bit more about
> my actual implementation in the Hurd itself. I've done added a bit more
> to the proposal to explain what I feel is a good implementation.
> Basically, I was thinking the network stack could be divided into
> diff
Hi,
> I dont know if this is the right list for this question. I apologize
> if it is the wrong forum.
No worries, this is the right one. :-)
> I am quite unsure which project to choose from the list. I originally
> applied for procfs project and i got a suggestion to apply for another
> pro
Hi,
> I want to bring few points to your notice, though I had understood
> the need for GNU/Linux compatibility of the procfs that is to be
> implemented, I always felt that the GNU System should be always ahead of
> the GNU/Linux or anyother systems, either in terms of design, or
> performance
16 matches
Mail list logo
