Re: GSoC Project Proposal for GNU/Hurd and Rust

; a wide array of new > skills through this project! This is my first time working with open source > contribution and > looking for some experience in this field, I am deeply interested in this > domain of problems and > would want to discuss about a prospective proposal! > Tha

RE: GSoC Project Proposal for GNU/Hurd and Rust

looking for some experience in this field, I am deeply interested in this domain of problems and would want to discuss about a prospective proposal! Thank you for your consideration, Vedant

Re: Regarding the Current Hurd Logo (Update Proposal)

>I don't really have a strong opinion :) Hi, Samuel. Thatks okay, it's still good to hear from you! (Sorry if this email appears twice in your inbox. I forgot to reply to the mailing list to make it public. It's a bad habit of mine) >I find this interesting. This is a bit more... Symbolic, I

Re: Regarding the Current Hurd Logo (Update Proposal)

Hello, I don't really have a strong opinion :) Muto, le mer. 27 mars 2019 23:16:39 +0100, a ecrit: > - Bigger arrows. The Hurd logo is kind of hard to make out from far > away, Agreed :) > - Rounded edges. Something I like about the Hurd system is how hard > it is to actually "cut" yourself

Re: Regarding the Current Hurd Logo (Update Proposal)

Muto writes: > Hello, bug-hurd, > Looks good. I'm all for changing the logo to this new one. > Over the past few weeks I've been working with Inkscape on re-drawing > the "Hurd Boxes" logo (it should be attached to this email). Of course > it's not much different at all from the current one (I

Regarding the Current Hurd Logo (Update Proposal)

Hello, bug-hurd, Over the past few weeks I've been working with Inkscape on re-drawing the "Hurd Boxes" logo (it should be attached to this email). Of course it's not much different at all from the current one (I respect McCamant and Schwinge too much to throw away their work), it differs in a few

Re: GSoC 2016 proposal

On Sun, Mar 13, 2016 at 11:40:45AM +, Vasantha Ganesh K wrote: > Hello Braun, >   Thanks for your attention. I'll tone the next draft down and make it a > little more formal. No you didn't get it. I was meaning that your enthusiasm makes you say plain wrong things like "the Hurd can scale wel

Re: GSoC 2016 proposal

On Sat, Mar 12, 2016 at 06:51:40AM +, Vasantha Ganesh K wrote: >   Please review my GSoC proposal that I have attached with this mail. I know > its rough, please send some suggestions. > The fact that GNU Hurd can scale well because of its architecture and its a > part of

GSoC 2016 proposal

Hello all,   Please review my GSoC proposal that I have attached with this mail. I know its rough, please send some suggestions. Thanks, Vasantha Ganesh K Contact info Name : Vasantha Ganesh K email address : vasanthaganes...@tuta.io IRC nick

[proposal] Move defpager from hurd to incubator repo

Hi all, currently at least 2 pagers are distributed with the Hurd: "mach-defpager", which it's the default pager and "defpager". Although the last it's not finished (see TODO) and it's not used it's also in the Hurd repo. I'm not sure if it's in a state where can be used. I propose to move de

Thanks for accepting my proposal

Dear all. Thank you for accepting my proposal. I am so happy and excited when I read the accept email this morning. Thank you all give me the chance to join this wonderful project. Many thanks to my mentor Thomas Schwinge for your patient mentoring. I will show my best to the open source world

Re: forwarded proposal to finance some hurd work

Hi, On Wed, May 18, 2011 at 12:54:27PM +0200, Thomas Schwinge wrote: > On Tue, 17 May 2011 21:19:57 +0200, Tanguy LE CARROUR > wrote: > > let me know if you have a "top 5" list of simple things that have to > > be done. > > Simple things... What's that? ;-) I'll try to think about some. > Ar

Re: forwarded proposal to finance some hurd work

Hallo! On Tue, 17 May 2011 21:19:57 +0200, Tanguy LE CARROUR wrote: > I thought about "refreshing" the web site sometimes ago. No need to redo > everything... one can do a lot with just CSS Styling. Sure! If you'd like to work on that, see here for starters:

Re: forwarded proposal to finance some hurd work

Hallo! On Tue, 10 May 2011 21:07:31 +0200, Tanguy LE CARROUR wrote: > 2011/5/7 > > More importantly however -- as I stated before -- I have serious doubts > > about the usefulness of small monetary rewards. > > > According to the reaction we got (...none...) I'm also starting to be a > bit skep

Re: forwarded proposal to finance some hurd work

Hi! An thanks for the answer... 2011/5/16 > On Tue, May 10, 2011 at 09:07:31PM +0200, Tanguy LE CARROUR wrote: > > what exactly is a "community and outreach manager"?! > Basically, someone who takes care of all the non-development tasks that > need to be done, but usually are not adequately ha

Re: forwarded proposal to finance some hurd work

Hi, On Tue, May 10, 2011 at 09:07:31PM +0200, Tanguy LE CARROUR wrote: > what exactly is a "community and outreach manager"?! Basically, someone who takes care of all the non-development tasks that need to be done, but usually are not adequately handled through volunteer work alone: making sure

Re: forwarded proposal to finance some hurd work

Hi! 2011/5/7 > More importantly however -- as I stated before -- I have serious doubts > about the usefulness of small monetary rewards. > According to the reaction we got (...none...) I'm also starting to be a bit skeptical. :-( GSoC works, because Google is paying more or less a normal salary

Re: forwarded proposal to finance some hurd work

Hi, On Wed, Apr 20, 2011 at 12:33:24PM +0200, Thomas Schwinge wrote: > For the GSoC, we got more good applications than we can accept (which > is obviously limited by Google). My idea is that we could perhaps use > the money Tanguy is offering for paying another GSoC project on our > own? It's

Re: forwarded proposal to finance some hurd work

On Wednesday 20 April 2011 12:33:24 Thomas Schwinge wrote: > (I'm assuming you're somewhat familiar with the Google Summer of Code; if > not please say so.) For the GSoC, we got more good applications than we > can accept (which is obviously limited by Google). My idea is that we > could perhaps

Re: forwarded proposal to finance some hurd work

Hallo! (I'm assuming you're somewhat familiar with the Google Summer of Code; if not please say so.) For the GSoC, we got more good applications than we can accept (which is obviously limited by Google). My idea is that we could perhaps use the money Tanguy is offering for paying another GSoC pr

Re: forwarded proposal to finance some hurd work

gt; Assuming this is a serious proposal -- and you seem to be serious about > it :-) -- which amount of money are we roughly talking about? (Of > course, it is fine to reply privately.) > mmm... few hundreds E/CHF/$! Most likely 500-600 this year!? Cheers, Tanguy

Re: forwarded proposal to finance some hurd work

Hallo! On Fri, 25 Mar 2011 14:42:59 +0100, Tanguy LE CARROUR wrote: > So recently I made a decision. If I have not time to work on [the GNU > Hurd], maybe I should pay someone to do it for me? Assuming this is a serious proposal -- and you seem to be serious about it :-) -- which amo

Re: forwarded proposal to finance some hurd work

On 04/05/2011 12:14 AM, Thomas Schwinge wrote: > Marcus, is the g10 Code Hurd Maintenance Point offering still > appropriate? That one is stale. Maybe something could be arranged if there is interest. > Hurd developers, please talk to me or add yourself to that page if you > feel like you should

Re: forwarded proposal to finance some hurd work

Hallo! What the others said. For me, too, it's much more of a time scheduling issue than a money one. That said, we have this page, , where we have a list of GNU Hurd developers (admittedly, a very, very sparse list; disclaimer: I'm on that list), an

Re: forwarded proposal to finance some hurd work

2011/3/29 Samuel Thibault > Arne Babenhauserheide, le Tue 29 Mar 2011 18:05:32 +0200, a écrit : > > For me it sould be like : hey guys, can one of you take a week off and > work > > 100% on the Hurd?... we pay you for that! :-D > I just can't take a week off. Money is not the issue. > The worst t

Re: forwarded proposal to finance some hurd work

Tanguy LE CARROUR, le Tue 29 Mar 2011 18:28:26 +0200, a écrit : > What about the students of the GSoC? Do they get paid? Sure they do. > Can't we "hire" more?! As many as Google gives us. And they are not really like maintainers, they need to get mentored etc. Samuel

Re: forwarded proposal to finance some hurd work

Arne Babenhauserheide, le Tue 29 Mar 2011 18:05:32 +0200, a écrit : > For me it sould be like : hey guys, can one of you take a week off and work > 100% on the Hurd?... we pay you for that! :-D I just can't take a week off. Money is not the issue. Samuel

forwarded proposal to finance some hurd work

forwarded from help-hurd On Sunday 27 March 2011 16:04:55 Tanguy LE CARROUR wrote: Hi, 2011/3/26 Robert Brockway > Quite a number of organisations exist to manage the finances of OSS > projects, eg SPI[1]. The "problem" is how do the developers get the money if they are not "officially working

Re: another "xmlfs" proposal

Hi, On Sat, May 03, 2008 at 11:53:18AM -0700, [EMAIL PROTECTED] wrote: > DOM is a(n object) model for xml documents. In principle, using it or > not is not the point. I think antrik wanted to say to translate the > data model of the xml document to an directory structure so that the > file _path_

another "xmlfs" proposal

On Wed, 30 Apr 2008 01:11:49 +0200, antrik wrote: > It could be possible though to pick one simple unambiguos XPath syntax > and use it for the static representation of the document contents... > That's why the task suggested considering the tree representation with a > view on both DOM *and* XPat

Re: Requesting to Review of the proposal - Improved NFS Implementation

Hi, On Fri, Apr 11, 2008 at 02:02:49AM +0530, Madhusudan C.S wrote: > >The next stage of this project starts with implementing the core > > >NFSv3 protocols. > > [...] > > >3. Additional file attributes in many replies including fourth > > >set of permission bits > > > > Is that

Re: Requesting to Review of the proposal - Improved NFS Implementation

etattr, setattr, root, lookup, statfs, > > readdir etc which are not present in the current implementation but > > part of the NFS's Remote Procedure Calls(RPC). > > Could you give a short summary what these do? Hey I am sorry. I have put the words wrongly here. Actually I m

Re: Requesting for review of the Draft proposal for - procfs

Hi, Sorry for the late reply... On Sun, Mar 30, 2008 at 01:07:15AM +0530, Madhusudan C.S wrote: > I have submitted a totally reworked proposal through Google Web App. > [...] > The project thus aims at making the GNU/Linux process management tools > like ps, top, vmstat, sysctl, w,

Re: Requesting to Review of the proposal - Improved NFS Implementation

Hi, I'm asking about a couple of specific points of your proposal here. I'll add some more generic remarks in GSoC web application. On Wed, Apr 02, 2008 at 04:07:38PM +0530, Madhusudan C.S wrote: > I will work on improving the performance of NFSv2 and fixing bugs that > exist on

Requesting to Review of the proposal - Improved NFS Implementation

Hi Olaf and all, My proposal is given below. I request you to review it and give suggestions on any kind of mistakes so that I can improve my proposal. Greetings! I wish to provide an improved Network Filesystem support to "the Hurd". This implementation

Re: Hurdish TCP stack (was: updated proposal)

Okay, I understand. I think part of this goes back to a question on the reason for enumeration on these sockets (tcp0, tcp1, etc.) if they aren't used directly in the socket interface for the developer. I assumed it was as a convenience for other programs that were monitoring the network. I agre

Re: Hurdish TCP stack (was: updated proposal)

On Tue, Apr 01, 2008 at 08:07:23AM -0600, Joshua Stratton wrote: > > It's clearly a mistake to map the directory tree to the protocols stack. > > The TCP implementation is a global layer, it handles network interfaces > > internally and must not be bound to any interface (ask yourself how to > > im

Re: Hurdish TCP stack (was: updated proposal)

> > > > I think this approach would fit nicely into the Hurd's translator > > architecture. However, I'm not sure if I like the directory structure > they > > use. I would think the network interface should be shown like > > > > /net/eth0/tcp/2 > > > > It might be worthwhile--but possible bad sty

Re: Hurdish TCP stack (was: updated proposal)

On Mon, Mar 31, 2008 at 02:07:26PM -0600, Joshua Stratton wrote: > If anyone hasn't read up on how Plan9 runs their network stack, they have a > separate directory of each connection. An example in the paper is shown as > the following, > > # cd /net/tcp/2 <--- this is like the second TCP conne

Re: Hurdish TCP stack (was: updated proposal)

If anyone hasn't read up on how Plan9 runs their network stack, they have a separate directory of each connection. An example in the paper is shown as the following, # cd /net/tcp/2 <--- this is like the second TCP connection # ls -l ctl data listen local remote status They use an interesting

Re: Hurdish TCP stack (was: updated proposal)

Hey, I did some reading up on the Plan9 design for their network hierarchy. I think it's interesting. I wouldn't mind using it just so the layout would be more commonplace (for those who may have used Plan9). I also like the access to the interface statistics. Plan9, from what I've read, tries

Re: Requesting for review of the Draft proposal for - procfs

Hi, On Sun, Mar 30, 2008 at 01:35:34PM +0200, Carl Fredrik Hammar wrote: > <[EMAIL PROTECTED]> writes: > > I totally agree that it would be desirable to have a library that help > > writing such *really* trivial translators. (libtrivtrivfs?... ;-) ) > > (Looking in a thesaurus.) How about, micr

Overlapping applications (was: Requesting for review of the Draft proposal for - procfs)

Hi, On Sun, Mar 30, 2008 at 01:43:54PM +0200, Carl Fredrik Hammar wrote: > > BTW, there is a problem: We have another very promising application > > for the procfs task. If we want to take both of you, one would have > > to switch to a different task. Would you be willing to work on > > something

Hurdish TCP stack (was: updated proposal)

Hi, On Sat, Mar 29, 2008 at 05:04:48PM +0100, Carl Fredrik Hammar wrote: > > /ip/eth0/tcp/ /ip/eth0/udp/ /ip/eth1/tcp/ /ip/eth1/udp/ /ip/lo/tcp/ > > /ip/lo/udp/ /ip/tcp/ /ip/udp/ [...] > Shouldn't it be /eth0/ip/tcp/? I.e. with internet protocol is layered > over ethernet. Indeed, the more I th

Re: Requesting for review of the Draft proposal for - procfs

Hi, On Sat, Mar 29, 2008 at 11:29:10PM +0100, Carl Fredrik Hammar wrote: > "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, > > pgrep, free, tload, uptime, fuser,

Re: Requesting for review of the Draft proposal for - procfs

Hi, > BTW, there is a problem: We have another very promising application for > the procfs task. If we want to take both of you, one would have to > switch to a different task. Would you be willing to work on something > else as well? I know it's unfortunate, as you have already put so much > work

Re: Requesting for review of the Draft proposal for - procfs

Hi, <[EMAIL PROTECTED]> writes: > I totally agree that it would be desirable to have a library that help > writing such *really* trivial translators. (libtrivtrivfs?... ;-) ) (Looking in a thesaurus.) How about, micro, puny, trite, scanty...? Wait I think we have a winner libweefs. ;-) > I thi

Re: Requesting for review of the Draft proposal for - procfs

Hi, > > I'm fully available this summer without any other commitments, will > > tune my day/night rhythm as per my mentor's requirement and assure a > > dedicated work of 50 hours/week. > > Wow, 50 hours a week is a lot. I didn't put nearly as much time into > my GSoC project, I think 2

Re: Requesting for review of the Draft proposal for - procfs

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,

Re: Requesting for review of the Draft proposal for - procfs

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 >

Re: Requesting for review of the Draft proposal for - procfs

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

Re: updated proposal

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

Re: Requesting for review of the Draft proposal for - procfs

This is > > problematic, because if the project turns out harder than expected, > > and you can't complete it all, we are left with no visible > > improvement at all... > > > I am sorry but I still want to mention that there is no room to think > whether I would

Re: Requesting for review of the Draft proposal for - procfs

we need a special library for that... I don't see procfs having any special requirements compared to other virtual filesystems. Maybe the problem is that you do not have enough understanding yet about what libnetfs does... (Don't let yourself be mislead by the misnaming!) > Thanks a lot, but I

Re: Requesting for review of the Draft proposal for - procfs

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, sys

Re: Requesting for review of the Draft proposal for - procfs

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

Re: updated proposal

Thanks for the feedback. Josh On Sat, Mar 29, 2008 at 10:04 AM, Carl Fredrik Hammar <[EMAIL PROTECTED]> wrote: > 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

Re: updated proposal

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 coul

Re: Requesting for review of the Draft proposal for - procfs

ill continue my commitments with "the Hurd" community. We > will always have some visible improvements. I have mentioned in the > proposal why "the Hurd" is so close to my heart and why I contribute to > the GNU system, also why I chose Hurd of all the other organi

Re: Requesting for review of the Draft proposal for - procfs

Hi Olaf, Fredrick and all, Thanks a lot for all the suggestions and comments. I am sorry for all the misconceptions. I am reworking on the entire proposal so that meets the requirements of "the Hurd" community. I want to bring few points to your notice, though I had unde

updated proposal

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

Re: Requesting for review of the Draft proposal for - procfs

<[EMAIL PROTECTED]> writes: > I don't quite see the need for a special library here -- what would it > provide over plain libtrivfs?... 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 produ

Re: Requesting for review of the Draft proposal for - procfs

Hi, On Wed, Mar 26, 2008 at 10:07:53PM +0100, Carl Fredrik Hammar wrote: > I was the student in GSoC last year, just thought I'd share my > acquired wisdom and drop some comments on your proposal. :-) Thanks for that :-) > Also, procfs is mainly used to provide compatibility w

Re: Requesting for review of the Draft proposal for - procfs

Hi, On Wed, Mar 26, 2008 at 09:21:08PM +0530, Madhusudan C.S wrote: > I have come up with this draft proposal so that we can discuss > further based on the this proposal. It looks very promising already :-) > Please review it and suggest any kind of mistakes including spell

Re: Requesting for review of the Draft proposal for - procfs

Hi, > Hi Carl, > Thanks a lot in spending your invaluable time in going through my > proposal. No problem. Also, I go by Fredrik not Carl, a misconception that is easy to make since I don't abbreviate it. :-) > [snip] > > I suspect you will need to narrow down your f

Re: Requesting for review of the Draft proposal for - procfs

Hi Carl, Thanks a lot in spending your invaluable time in going through my proposal. Gave it a quick read-through and it looks pretty good to me. I'm not > that familiar with procfs though, I've mostly just used it to set some > networking settings and checking my notebooks ba

Re: Requesting for review of the Draft proposal for - procfs

Hi, I was the student in GSoC last year, just thought I'd share my acquired wisdom and drop some comments on your proposal. :-) > [snip] > > I have come up with this draft proposal so that we can discuss further > based on the this proposal. I have roughly consolidated

Requesting for review of the Draft proposal for - procfs

de in hurdextras repo and Documentation in it, going through many other websites and tutorials, and more importantly considreing the suggestions olaf gave me, I have come up with a rough initial draft of the proposal I want to submit for GSoC 2008, with Hurd as my mentoring organization. The project

Re: My proposal for `PATH_MAX' and friends

Hello! On Thu, Apr 12, 2007 at 01:59:44PM -0700, Roland McGrath wrote: > I appreciate the intent of your suggestion, but I don't think it can > actually meet its goals. I agree. I surrender. I have to. On a technical basis. Thanks for pointing this out. I totally missed the two cases ``globa

Re: My proposal for `PATH_MAX' and friends (was: What is ``access (NULL, whatever)'' supposed to do?)

I appreciate the intent of your suggestion, but I don't think it can actually meet its goals. I don't think that defining PATH_MAX invalidly will actually be a net gain at all. If defined, PATH_MAX must be a constant. If you have a plan and you cannot compile: static char name[PATH_MAX]

Re: My proposal for `PATH_MAX' and friends (was: What is ``access (NULL, whatever)'' supposed to do?)

At Wed, 11 Apr 2007 10:56:18 +0200, Neal H. Walfield wrote: > > At Tue, 10 Apr 2007 22:10:01 -0700, > Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > > > > [1 ] > > On Tue, 2007-04-10 at 21:44 +0200, Thomas Schwinge wrote: > > > Hello! > > > > > > We're still being again and again annoyed by p

Re: Setting ones's priorities (was: My proposal for `PATH_MAX' and friends)

On Wed, 2007-04-11 at 12:57 +0200, Thomas Schwinge wrote: > Hello! > > On Tue, Apr 10, 2007 at 10:10:01PM -0700, Thomas Bushnell BSG wrote: > > On Tue, 2007-04-10 at 21:44 +0200, Thomas Schwinge wrote: > > > We're still being again and again annoyed by programs that use `PATH_MAX' > > > unconditio

Setting ones's priorities (was: My proposal for `PATH_MAX' and friends)

Hello! On Tue, Apr 10, 2007 at 10:10:01PM -0700, Thomas Bushnell BSG wrote: > On Tue, 2007-04-10 at 21:44 +0200, Thomas Schwinge wrote: > > We're still being again and again annoyed by programs that use `PATH_MAX' > > unconditionally. > > Why stop with this one? So, if I interpret things correct

Re: My proposal for `PATH_MAX' and friends (was: What is ``access (NULL, whatever)'' supposed to do?)

Hi, On Wed, Apr 11, 2007 at 10:56:18AM +0200, Neal H. Walfield wrote: > Legacy compatibility has always ruled the day. Standards compatibility, not bug compatibility... -antrik- ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman

Re: My proposal for `PATH_MAX' and friends (was: What is ``access (NULL, whatever)'' supposed to do?)

At Tue, 10 Apr 2007 22:10:01 -0700, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > > [1 ] > On Tue, 2007-04-10 at 21:44 +0200, Thomas Schwinge wrote: > > Hello! > > > > We're still being again and again annoyed by programs that use `PATH_MAX' > > unconditionally. > > Why stop with this one?

Re: My proposal for `PATH_MAX' and friends (was: What is ``access (NULL, whatever)'' supposed to do?)

On Tue, 2007-04-10 at 21:44 +0200, Thomas Schwinge wrote: > Hello! > > We're still being again and again annoyed by programs that use `PATH_MAX' > unconditionally. Why stop with this one? Let's just drop all the Hurd features and implement the same interface as Linux, as exactly as we can make i

My proposal for `PATH_MAX' and friends (was: What is ``access (NULL, whatever)'' supposed to do?)

Hello! We're still being again and again annoyed by programs that use `PATH_MAX' unconditionally. I propose the following: we define it in glibc. But wait, we don't just define it, we also try to help the programmer. It works roughly as follows: To `[glibc]/include/libc-symbols.h' we add: #v

Re: [EMAIL PROTECTED]: GSoC proposal, device driver glue code]

Hi, On Fri, Mar 23, 2007 at 10:49:40PM -0400, Barry deFreese wrote: > how hard would it be to generalize the "glue layer" and let us load > drivers as modules instead? Not sure what you mean. Generalize in what regard? -antrik- ___ Bug-hurd mailing

Re: [EMAIL PROTECTED]: GSoC proposal, device driver glue code]

feasible than write a new GNUMach API to made porting Linux 2.6/ BSD device drivers more easy or at least to write GNUMach drivers natively ,instead use drivers from other O.S? Writing native drivers is just not possible, there should be a lot more developers. In addition, the proposal is to

Re: [EMAIL PROTECTED]: GSoC proposal, device driver glue code]

at first, thank you all for you kind comments and for the time you spent reading my proposal. I will try to be as precise as possible. Something missing in this proposal is how to deal with runtime changes, especially for USB devices. that's true. there are a lot of things missing m

Re: [EMAIL PROTECTED]: GSoC proposal, device driver glue code]

han write > a new GNUMach API to made porting Linux 2.6/ BSD device drivers more easy or > at least to write GNUMach drivers natively ,instead use drivers from other > O.S? Writing native drivers is just not possible, there should be a lot more developers. In addition, the proposal is to re

Re: [EMAIL PROTECTED]: GSoC proposal, device driver glue code]

On 3/23/07, Richard Braun <[EMAIL PROTECTED]> wrote: I like this proposal but I also have a question : did you consider BSD drivers ? I understand you have experience with Linux drivers, and this is a very good reason to work on a glue code for them, but from what I could see (at least th

Re: [EMAIL PROTECTED]: GSoC proposal, device driver glue code]

r profound impression to me. > > Feel free to directly reply to , of course. I like this proposal but I also have a question : did you consider BSD drivers ? I understand you have experience with Linux drivers, and this is a very good reason to work on a glue code for them, but from what I c

Re: [EMAIL PROTECTED]: GSoC proposal, device driver glue code]

ound impression to me. > > Feel free to directly reply to , of course. Not bad. Something missing in this proposal is how to deal with runtime changes, especially for USB devices. There were a lot of changes between Linux 2.4 and 2.6, but most of them were related to dynamic configurations and S

GSoC proposal, device driver glue code

Hi there! This is my first mail to the list. I'm interested in submitting an application to GSoC for the Hurd project concerning the device driver glue code. The proposal is @ http://www.cslab.ntua.gr/~ananos/proposal.html my first try for the abstract produced this: The GNU/Hurd runni

Re: An idea and proposal about system time

On Sat, 2007-02-17 at 11:06 +0100, Thomas Schwinge wrote: > Looking at the source code, I see that it is used inside `pfinet' for > timing issues and a few times in the file system servers. These "few times" are crucial; every single time a file access is performed, a timestamp needs to be marked

Re: An idea and proposal about system time

[EMAIL PROTECTED], le Sat 17 Feb 2007 07:39:22 +0100, a écrit : > On Fri, Feb 16, 2007 at 02:44:46PM +0100, Thomas Schwinge wrote: > > > An open issue to me so far is if we can find an efficient way to > > continue providing `libshouldbeinlibc''s `maptime' interface. > > The real question to ask

Re: An idea and proposal about system time

#x27; interface. > > The real question to ask is: Why did the original Mach designers pay so > much attention to an efficient way of getting the system time -- and are > their reasons relevant to us? > > If the answer is that they aren't, I guess your proposal is fine, and >

Re: An idea and proposal about system time

much attention to an efficient way of getting the system time -- and are their reasons relevant to us? If the answer is that they aren't, I guess your proposal is fine, and maptime() can really be dropped alltogether. If the the anser is that they might be, your proposal could be problematic

An idea and proposal about system time

Hello! This is for one an attempt to solve ``gnumach should be able to handle local time in RTC'' in an elegant way, but -- while actually achieving that -- also quickly goes one sphere further. It's about system time. There are currently two possible ways t

A Proposal For Co-operation With Me

HELLO, PLEASE BEAR WITH ME FOR NOW AND DO NOT ASK MY NAME. WHAT I HAVE MAY BE OF INTEREST TO YOU.IT IS A BUSINESS PROPOSAL THAT WILL BE BENEFICIAL TO YOU AND I. I LIVE IN SHANGHAI,CHINA. I AM 51 YEARS OLD AND I HAVE BEEN WORKING IN A BANK IN

Re: Review of Thomas's >2GB ext2fs proposal

Thomas Bushnell BSG wrote: Ognyan Kulev <[EMAIL PROTECTED]> writes: Just a small techical correction: we remove mapping only when we are remapping page to contain another block. So when page is evicted, it continues to map the same disk block until ext2fs decides that we want this page to hold ano

Re: Review of Thomas's >2GB ext2fs proposal

"Neal H. Walfield" <[EMAIL PROTECTED]> writes: > In memory. But I don't need a linked list. How do you keep track of the extant mappings? Thomas ___ Bug-hurd mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Review of Thomas's >2GB ext2fs proposal

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: >> I evict when the kernel evicts. This keeps the accounting data >> proportional to the data in core. > > How do you know when the kernel evicts? Ognyan modified libpager. He added the callback function pager_notify_pageout. -- Marco

Re: Review of Thomas's >2GB ext2fs proposal

"Neal H. Walfield" <[EMAIL PROTECTED]> writes: > Nope, the page is freed. The only memory that is consumed is the > associations in the two hashes. However, I have now become convinced > that the better strategy is to drop the association in the release > function if the kernel does not have a c

Re: Review of Thomas's >2GB ext2fs proposal

"Neal H. Walfield" <[EMAIL PROTECTED]> writes: > I am interested in the following detail of your plan: when do you > drain the cache? When it is full? If we set the cache size to 2GB > then you have a lot of mappings to manage. The hashes that I have are > proportional to the size of the kernel

Re: Review of Thomas's >2GB ext2fs proposal

> > The hashes and an array consisting of the reference count, a bit > > indicating if the page is in the kernel and another bit indicating if > > the page is allocated. > > I could perfectly well adopt exactly the same strategy, and use a > cheaper but less precise policy for dropping cached mapp

Re: Review of Thomas's >2GB ext2fs proposal

"Neal H. Walfield" <[EMAIL PROTECTED]> writes: > The hashes and an array consisting of the reference count, a bit > indicating if the page is in the kernel and another bit indicating if > the page is allocated. I could perfectly well adopt exactly the same strategy, and use a cheaper but less pre

Re: Review of Thomas's >2GB ext2fs proposal

At 17 Aug 2004 03:03:07 -0700, Thomas Bushnell BSG wrote: > > "Neal H. Walfield" <[EMAIL PROTECTED]> writes: > > > In memory. But I don't need a linked list. > > How do you keep track of the extant mappings? The hashes and an array consisting of the reference count, a bit indicating if the p

Re: Review of Thomas's >2GB ext2fs proposal

At 17 Aug 2004 03:07:14 -0700, Thomas Bushnell BSG wrote: > > Ognyan Kulev <[EMAIL PROTECTED]> writes: > > > You are probably confused because "map" can have 2 meanings: > > > > 1. Mapping page of address space to page of pager. > > 2. Mapping page of pager to disk block. > > > > And the curren

  1   2   >