Re: Fwd: Re: TODO list?

From: Paul Robinson (paul_at_iconoplex.co.uk)
Date: 06/30/03

  • Next message: Paul Robinson: "Re: Questions"
    Date: Mon, 30 Jun 2003 11:29:42 +0100
    To: wgrim@siue.edu
    
    

    On Sat, Jun 28, 2003 at 06:52:36PM -0500, wgrim@siue.edu wrote:

    > I have taken a look at the PR list before, but I get depressed when I look at
    > some of the requests. Some requests don't look very hard, but they require
    > hardware that I don't have. How do you guys go about handling bug fixes if you
    > don't happen to have certain hardware that someone else may have?

    I was thinking about this the other day. And yes, it was frustrating. I just
    went back and had another look at the list to see if there were any obvious
    purges - and then something interesting popped up. There are quite a few
    suspended or open PRs on older versions of FreeBSD, but nothing submitted
    for later versions, and the problem seems to have "disappered" - e.g.
    kern/2325 which was still a bug in 4.3-R, but I can't replicate in -CURRENT
    (unless I'm doing something wrong). Which suggests somebody has fixed it.
    Take a look at -CURRENT version of the relevant code, take a look at the
    older version, if you can spot the problem, suggest an MFC? It might help
    maintainers purge a big chunk.

    Or you can just go around begging for hardware.
     
    > Also, when you're working on a PR, do you roll your OS version back to whatever
    > the PR requires? If so, do you just cvsup downgrade your source and "make
    > buildworld... etc"?

    I have VMware. I can have a copy of every -RELEASE and an up-to-date
    -CURRENT on the go on the same machine all running at the same time if need
    be. Expect performance problems. :-) Unfortunately it costs money and means
    that for ease-of-use (trust me, the port is horrid) my main dev machine is a
    Windows box, but even so...
     
    > I have lots of interest in beginning some simple tasks with the kernel, but
    > it's quite difficult to know where to start. I'm good at C/C++ and have taken
    > an OS course; I just don't know how this particular kernel works on most levels.

    I took a look at this aaaaages ago. Back in late 2001. My main problem then
    was time. My current problem is getting bandwidth into my new home, but I do
    know that PRs are a good way of learning the OS, gets you known to
    maintainers, and ultimately helps purge a big, nasty database, everybody
    wishes was empty. I also know that very senior members of the project will
    give encouragement to anybody who helps purge PRs. My advice to you if you
    have the time, is just go for it. I'll be finally getting around to my own
    PR purging activities in a few weeks now that I have time, (soon!) bandwidth
    and a desire to stop drinking. Long story. Don't ask. Anyway....

    Good luck.

    -- 
    Paul Robinson
    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
    

  • Next message: Paul Robinson: "Re: Questions"

    Relevant Pages

    • Re: [00/17] Large Blocksize Support V3
      ... The number of requests that the driver can take is limited. ... I have a hard time believe that device hardware limits don't allow them ... date test on 32bit because the memory fragments faster. ... The bus pci/pcie/hypertransport already have block sizes below 4KB. ...
      (Linux-Kernel)
    • Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
      ... think pushing 6.2 into EoL is a bit rushed. ... i spent some time searching the PRs with the ... I was not able to find anything with respect to that hardware ... around 6.1 for us with Jack Vogels kind assistance (and hardware ...
      (freebsd-stable)
    • Re: File Fragmentation
      ... > reordering of actual hardware transfers to and from the disk platters) _is_ ... so it's not going to get much elevator reordering out of that. ... Scsi is better - I think 32 queues requests at a time is quite common. ... Ditto buffering. ...
      (comp.os.linux.misc)
    • Re: Im new. Its possible to..?
      ... > takes user requests handles them and converts them to block wise requests ... > to the hardware and sends them to a port/miniport driver for ATA ... An advanced things could be the possibility to deny ...
      (microsoft.public.development.device.drivers)
    • Re: RFC - how to balance Dirty+Writeback in the face of slow writeback.
      ... But these numbers are in no way tied to the hardware. ... thought that assuming any kind of reliable throttling at the queue level ... If there some reason relating to making the block layer work more ... there because the requests were statically allocated. ...
      (Linux-Kernel)