archive-org.com » ORG » N » NETBSD.ORG

Total: 1243

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • Platforms supported by NetBSD
    follows Generally speaking the port boots and works but keeping it working is the responsibility of the user community This includes but is not limited to kernel changes and toolchain upgrades Developers committing MI changes are still encouraged to keep ports up to date when it can be easily done MI architecture decisions may penalize organic ports if there is a benefit for focus ports If the port is not working at release time a release is done without the port and the port is moved down to the life support tier Currently there are 49 ports with Tier II status They are Port CPU Machines Latest Release acorn32 arm Acorn RiscPC A7000 NC and compatibles 7 0 algor mips Algorithmics MIPS evaluation boards 7 0 alpha alpha Digital Alpha 64 bit 7 0 amiga m68k Commodore Amiga MacroSystem DraCo 7 0 amigappc powerpc PowerPC based Amiga boards 7 0 arc mips Machines following the Advanced RISC Computing spec 7 0 atari m68k Atari TT030 Falcon Hades 7 0 bebox powerpc Be Inc s BeBox 7 0 cats arm Chalice Technology s Strong Arm evaluation board 7 0 cesfic m68k CES s FIC8234 VME processor board 7 0 cobalt mips Cobalt Networks Microservers 7 0 dreamcast sh3 Sega Dreamcast game console 7 0 epoc32 arm 32bit PSION EPOC PDA none emips mips Machines based on Extensible MIPS 7 0 evbsh3 sh3 Evaluation boards with Renesas Hitachi Super H SH3 and SH4 CPUs 7 0 ews4800mips mips NEC s MIPS based EWS4800 workstations 7 0 hp300 m68k Hewlett Packard 9000 300 and 400 series 7 0 hppa hppa Hewlett Packard 9000 700 series 7 0 hpcmips mips MIPS based Windows CE PDA machines 7 0 hpcsh sh3 Renesas Hitachi SH3 and SH4 based Windows CE PDA machines 7 0 ia64 itanium Itanium family of processors none ibmnws powerpc IBM Network Station Series 1000 7 0 iyonix arm Iyonix ARM pc 7 0 landisk sh3 SH4 based NAS appliances by I O DATA 7 0 luna68k m68k OMRON Tateisi Electronics LUNA series 7 0 mac68k m68k Apple Macintosh 7 0 macppc powerpc Apple Power Macintosh and clones 7 0 mipsco mips Mips family of workstations and servers 7 0 mmeye sh3 Brains mmEye Multi Media Server 7 0 mvme68k m68k Motorola MVME 68k SBCs 7 0 mvmeppc powerpc Motorola MVME PowerPC SBCs 7 0 netwinder arm StrongARM based NetWinder machines 7 0 news68k arm Sony s m68k based NET WORK STATION series 7 0 newsmips mips Sony s MIPS based NET WORK STATION series 7 0 next68k m68k NeXT 68k black hardware 7 0 ofppc powerpc Generic OpenFirmware compliant PowerPC machines 7 0 pmax mips Digital MIPS based DECstations and DECsystems 7 0 prep powerpc PReP PowerPC Reference Platform and CHRP machines 7 0 rs6000 powerpc MCA based IBM RS 6000 workstations 7 0 sandpoint powerpc Motorola Sandpoint reference platform 7 0 sbmips mips Broadcom SiByte evaluation boards 7 0 sgimips mips Silicon Graphics MIPS based workstations 7 0 shark arm Digital

    Original URL path: http://wiki.netbsd.org/ports/ (2016-02-01)
    Open archived version from archive

  • graphic chart
    output of the Quoting When quoting text from an outside source use double quotes and explicitly indicate its reference When you want to quote specific character s use single quotes For example all sentences end with a Files and directories Files and directories and in a wider sense paths should be emphasized e g fstab and rc conf are found under etc Commands options names and flags When a command or an executable are referenced they should be strongly emphasized same goes for their optional flags and arguments e g ls can be used to list the content of a directory and together with its a flag will output entries that start with a dot Functions or specific part of code Functions reference should be simply emphasized It is preferable to give the associated file explicitly to avoid confusions in that case use a colon to separate file name from function name Same goes when you want to pinpoint to specific zone in source files like lines For example the src bin print c printlong function is responsible for printing the long output from ls 1 On the usage of links You can find multiple types of links within the wiki links to other pages of this wiki index graphic chart this page explicit URLs with a label or without last but not least various services regarding NetBSD problem reports PR 1 man pages intro 1 hier 7 pkgsrc packages www apache security netpgp Always prefer using templates rather than hard coding paths for external URLs This helps both maintainability and readability Specific layouts The wiki support different commands shortcuts and templates that can help controlling the layout Code TBC Terminal console like output If you want to write series of commands eventually with their output you can use the

    Original URL path: http://wiki.netbsd.org/wiki/graphic_chart/ (2016-02-01)
    Open archived version from archive

  • CVS log for wikisrc/projects.mdwn
    7 18 1 lines Move general introductory text and the application form from htdocs into the wiki Revision 1 7 download view text markup annotated select for diffs Sun Nov 6 17 16 55 2011 UTC 4 years 2 months ago by jmmv Branches MAIN Diff to previous 1 6 preferred colored Changes since revision 1 6 1 0 lines Add support to define funded projects and open the section by adding a brief description of the SMP Networking project I need to extend this definition but this will be done later Revision 1 6 download view text markup annotated select for diffs Sun Nov 6 02 31 59 2011 UTC 4 years 2 months ago by jmmv Branches MAIN Diff to previous 1 5 preferred colored Changes since revision 1 5 2 1 lines A bunch of related changes Rename projects gsoc 2011 mdwn projects gsoc mdwn Rename projects gsoc 2011 ideas mdwn projects ideas mdwn Delete gsoc mdwn This removes the 2011 naming from files and directories projects proposals are not specific to a year It also gets rid of the now empty gsoc 2011 directory and the redundant top level gsoc mdwn page While doing this fix formatting of gsoc mdwn and ideas mdwn Revision 1 5 download view text markup annotated select for diffs Sun Nov 6 01 49 22 2011 UTC 4 years 2 months ago by jmmv Branches MAIN Diff to previous 1 4 preferred colored Changes since revision 1 4 7 0 lines Add the all and all flat projects lists The former lists all available projects properly sorted by category and difficulty while the latter shows a single page including an Atom RSS feed Note that the all page is also the place to spot misclassified projects as it includes a section

    Original URL path: https://wiki.netbsd.org/cgi-bin/cvsweb/wikisrc/projects.mdwn (2016-02-01)
    Open archived version from archive

  • Guidelines to apply for a project
    community If you are a newcomer e g you are a Google Summer of Code student that has just installed NetBSD for the first time you are encouraged to answer as many questions as possible If you are an old timer however you can skip the most obvious questions and focus on preparing a detailed project specification instead About your project What is the goal of the project Short overview What will be the deliverables of the project Code documentation Give an overview of how you intend to reach the project s goal in the form of milestones and a schedule Is similar software already available elsewhere e g for Linux or any other BSD Is the project a port of software or a rewrite remember No GPL in the NetBSD kernel About your project and NetBSD If your working area is the core NetBSD operating system have you installed NetBSD and made first experiences with hands on configuration Have you rebuilt the kernel and the userland either in full or in parts If you plan to work on pkgsrc have you installed packages from source and binary Have you created a package on your own Have you found the relevant places that your project is based on in the source code and read through it How will your project integrate into NetBSD Userland tool kernel subsystem driver patch set pkgsrc What interfaces in NetBSD will your project use Go into details here What module file names functions data structures etc are of relevance for your project To what degree are you familiar with those interfaces not some very details Is knowledge on other topics required for this project e g on hardware software other than NetBSD APIs protocols etc If so give details and references To what degree are

    Original URL path: http://wiki.netbsd.org/projects/application/ (2016-02-01)
    Open archived version from archive

  • All projects
    table Make TCP syncache optional Publish subscribe Unix sockets SMP Networking aka remove the big network lock Revamped struct protosw Virtual network stacks Port related projects Easy Medium Improve the SGI bootloader Optimize for R10k CPUs in machines like the SGI O2 Add support for mapping userspace via SMAP SMEP on newer x86 CPUs Hard Support for MIPS16e ISA Support for MMU less systems Port NetBSD to SGI Octane and Origin machines Support for sun4v UltraSPARC T1 Add IOMMU support in x86 xen ports Support latest features of Xen Other kernel level projects Easy Convert kernel printf to aprint or log Medium Binary compatibility for puffs backend More intelligent buffer queue management Make boot cfg handling machine independent Compressed Cache System Improved Automounter Support ISDN NT support and Asterisk integration Add directory notify to kqueue LED LCD Generic API Packet Latency Library Updated Atheros WiFi support Locking pages into memory redux NetBSD azure Bringing NetBSD to Microsoft Azure OpenCrypto swcrypto 4 enhancements Installable cache control or scheduling policies Add a kernel API for timed power on Make NetBSD a supported guest OS under VirtualBox Execute in place support Hard Lockless atomic FIFO LIFO queues Lockless atomic and generic Radix Patricia trees Graceful USB disk detach reattach Coordinated caching and scheduling support jails like features Kernel continuations Port dom0 to the ARM cpu architecture Blktap2 driver support Boot path cleanup to remove ifdef XEN clutter Dom0 hvm container support PVH Dom0 SMP support pv on hvm Paravirtualised Driver Support with drivers in an HVM container pvops pvh Runtime Paravirtualised Native Boot with PV drivers in an HVM container in PVH mode ACPI power management sleep wakeup support for Xen pvfb framebuffer video driver support frontend DRMKMS support gui support on dom0 RAM hot add Kernel Module support for Xen pmap Direct Map Superpage support 1G pvscsi driver support frontend backend pvusb driver support frontend backend libvirt support for Xen Language neutral interface specifications research Userland projects Easy Refactor Tabular Display Programs Inetd enhancements Add new features to inetd Curses library automated testing Improve and extend libintl Live upgrade BSD licensed rsync replacement WiFi browser Medium Make Anita support multiple virtual machine systems Create an SQL backend and statisticics query page for ATF test results Suffix and pattern rules in BSD make Light weight precision user level time reading Query optimizer for find 1 System level font handling in Unix Port launchd New LPR LPD for NetBSD Visualization tool for arbitrary network topology Secure PLT supporting RELRO binaries Sysinst alternative interface Make u boot compilable on NetBSD Hard Refactoring Aid for C Normalize and Summarize Email Threads Web UI for NPF BSD licensed troff nroff replacement Verification tool for NetBSD32 Desktop projects Easy Medium Desktop infrastructure Move beyond TWM User interface plugins for games Hard User switching with a secure attention key pkgsrc projects Easy Improve libvirt support in NetBSD pkgsrc Version control config files Port Mancoosi to pkgsrc Spawn support in pkgsrc tools Authentication server meta package Medium Bulk build tracker

    Original URL path: http://wiki.netbsd.org/projects/all/ (2016-02-01)
    Open archived version from archive

  • All projects
    Compare And Store operations the returned item should stay accessible for some indeterminate time so that other interrupted or concurrent callers to this function with this q can continue to deference it without trapping void atomic qpush fifo atomic queue t q void item Places item at the tail of the atomic queue t queue at q void atomic qpush lifo atomic queue t q void item Places item at the head of the atomic queue t queue at q Posted in the wee hours of Wednesday night November 10th 2011 Tags category kernel difficulty hard funded project smp networking status active Comment Lockless atomic and generic Radix Patricia trees Contact tech kern board core Funded by The NetBSD Foundation This project proposal is a subtask of smp networking and is elegible for funding independently The goal of this project is to implement lockless atomic and generic Radix and Patricia trees BSD systems have always used a radix tree for their routing tables However the radix tree implementation is showing its age Its lack of flexibility it is only suitable for use in a routing table and overhead of use requires memory allocation deallocation for insertions and removals make replacing it with something better tuned to today s processors a necessity Since a radix tree branches on bit differences finding these bit differences efficiently is crucial to the speed of tree operations This is most quickly done by XORing the key and the tree node s value together and then counting the number of leading zeroes in the result of the XOR Many processors today ARM PowerPC have instructions that can count the number of leading zeroes in a 32 bit word and even a 64 bit word Even those that do not can use a simple constant time routine to count them int clz unsigned int bits int zeroes 0 if bits 0 return 32 if bits 0xffff0000 bits 0xffff0000 else zeroes 16 if bits 0xff00ff00 bits 0xff00ff00 else zeroes 8 if bits 0xf0f0f0f0 bits 0xf0f0f0f0 else zeroes 4 if bits 0xcccccccc bits 0xcccccccc else zeroes 2 if bits 0xaaaaaaaa bits 0xaaaaaaaa else zeroes 1 return zeroes The existing BSD radix tree implementation does not use this method but instead uses a far more expensive method of comparision Adapting the existing implementation to do the above is actually more expensive than writing a new implementation The primary requirements for the new radix tree are Be self contained It cannot require additional memory other than what is used in its data structures Be generic A radix tree has uses outside networking To make the radix tree flexible all knowledge of how keys are represented has to be encapsulated into a pt tree ops t structure with these functions bool ptto matchnode const void foo const void bar pt bitoff t max bitoff pt bitoff t bitoffp pt slot t slotp Returns true if both foo and bar objects have the identical string of bits starting at bitoffp and ending before max bitoff In addition to returning true bitoffp should be set to the smaller of max bitoff or the length in bits of the compared bit strings Any bits before bitoffp are to be ignored If the string of bits are not identical bitoffp is set to the where the bit difference occured slotp is the value of that bit in foo and false is returned The foo and bar if not NULL arguments are pointers to a key member inside a tree object If bar is NULL then assume it points to a key consisting of entirely of zero bits bool ptto matchkey const void key const void node key pt bitoff t bitoff pt bitlen t bitlen Returns true if both key and node key objects have identical strings of bitlen bits starting at bitoff The key argument is the same key argument supplied to ptree find filtered node pt slot t ptto testnode const void node key pt bitoff t bitoff pt bitlen t bitlen Returns bitlen bits starting at bitoff from node key The node key argument is a pointer to the key members inside a tree object pt slot t ptto testkey const void key pt bitoff t bitoff pt bitlen t bitlen Returns bitlen bits starting at bitoff from key The key argument is the same key argument supplied to ptree find filtered node All bit offsets are relative to the most significant bit of the key The ptree programming interface should contains these routines void ptree init pt tree t pt const pt tree ops t ops size t ptnode offset size t key offset Initializes a ptree If pt points at an existing ptree all knowledge of that ptree is lost The pt argument is a pointer to the pt tree t to be initialized The ops argument is a pointer to the pt tree ops t used by the ptree This has four members The ptnode offset argument contains the offset from the beginning of an item to its pt node t member The key offset argument contains the offset from the beginning of an item to its key data This is used if 0 is used a pointer to the beginning of the item will be generated void ptree find filtered node pt tree t pt const void key pt filter t filter void filter ctx The filter argument is either NULL or a function bool const void void int bool ptree insert mask node pt tree t pt void item pt bitlen t masklen bool ptree insert node pt tree t pt void item void ptree iterate pt tree t pt const void node pt direction t direction void ptree remove node pt tree t pt const pt tree ops t ops void item Posted in the wee hours of Wednesday night November 10th 2011 Tags category kernel difficulty hard funded project smp networking status active Comment Fast protocol and port demultiplexing Contact tech kern tech net board core Funded by The NetBSD Foundation This project proposal is a subtask of smp networking and is elegible for funding independently The goal of this project is to enhance the networking protocols to process incoming packets more efficiently The basic idea is the following when a packet is received and it is destined for a socket simply place the packet in the socket s receive PCQ see atomic pcq and wake the blocking socket Then the protocol is able to process the next packet The typical packet flow from ip input is to rip tcp udp input which Does the lookup to locate the socket which takes a reader lock on the appropriate pcbtable s hash bucket If found and in the proper state Do not lock the socket since that would might block and therefore stop packet demultiplexing pcq put the packet to the pcb s pcq kcont schedule the worker continuation with small delay 100ms See kernel continuations Lock the socket s cvmutex Release the pcbtable lock If TCP and in sequence then if we need to send an immediate ACK Try to lock the socket If successful send an ACK Set a flag to process the PCQ cv signal the socket s cv Release the cvmutex If not found or not in the proper state Release the pcb hash table lock Posted in the wee hours of Wednesday night November 10th 2011 Tags category networking difficulty hard funded project smp networking status active Comment Implement per interface interrupt handling Contact tech kern tech net board core Funded by The NetBSD Foundation This project proposal is a subtask of smp networking and is elegible for funding independently The goal of this project is to implement interrupt handling at the granularity of a networking interface When a network device gets an interrupt it could call iftype defer ifp to schedule a kernel continuation see kernel continuations for that interface which could then invoke iftype poll Whether the interrupted source should be masked depends on if the device is a DMA device or a PIO device This routine should then call ifp if poll ifp to deal with the interrupt s servicing During servicing any received packets should be passed up via ifp if input ifp m which would be responsible for ALTQ or any other optional processing as well as protocol dispatch Protocol dispatch in iftype input decodes the datalink headers if needed via a table lookup and call the matching protocol s pr input to process the packet As such interrupt queues e g ipintrq would no longer be needed Any transmitted packets can be processed as can MII events Either true or false should be returned by if poll depending on whether another invokation of iftype poll for this interface should be immediately scheduled or not respectively Memory allocation has to be prohibited in the interrupt routines The device s if poll routine should pre allocate enough mbufs to do any required buffering For devices doing DMA the buffers are placed into receive descripors to be filled via DMA For devices doing PIO pre allocated mbufs are enqueued onto the softc of the device so when the interrupt routine needs one it simply dequeues one fills in it in and then enqueues it onto a completed queue finally calls iftype defer If the number of pre allocated mbufs drops below a threshold the driver may decide to increase the number of mbufs that if poll pre allocates If there are no mbufs left to receive the packet the packets is dropped and the number of mbufs for if poll to pre allocate should be increased When interrupts are unmasked depends on a few things If the device is interrupting too often it might make sense for the device s interrupts to remain masked and just schedule the device s continuation for the next clock tick This assumes the system has a high enough value set for HZ Posted in the wee hours of Wednesday night November 10th 2011 Tags category networking difficulty hard funded project smp networking status active Comment Kernel continuations Contact tech kern board core Funded by The NetBSD Foundation This project proposal is a subtask of smp networking and is elegible for funding independently The goal of this project is to implement continuations at the kernel level Most of the pieces are already available in the kernel so this can be reworded as combine callouts softints and workqueues into a single framework Continuations are meant to be cheap very cheap These continuations are a dispatching system for making callbacks at scheduled times or in different thread interrupt contexts They aren t continuations in the usual sense such as you might find in Scheme code Please note that the main goal of this project is to simplify the implementation of SMP networking so care must be taken in the design of the interface to support all the features required for this other project The proposed interface looks like the following This interface is mostly derived from the callout 9 API and is a superset of the softint 9 API The most significant change is that workqueue items are not tied to a specific kernel thread kcont t kcont create kcont wq t wq kmutex t lock void func void kcont t void arg int flags A wq must be supplied It may be one returned by kcont workqueue acquire or a predefined workqueue such as sorted from highest priority to lowest wq softserial wq softnet wq softbio wq softclock wq prihigh wq primedhigh wq primedlow wq prilow lock if non NULL should be locked before calling func arg and released afterwards However if the lock is released and or destroyed before the called function returns then before returning kcont set mutex must be called with either a new mutex to be released or NULL If acquiring lock would block other pending kernel continuations which depend on other locks may be dispatched in the meantime However all continuations sharing the same set of wq lock ci need to be processed in the order they were scheduled flags must be 0 This field is just provided for extensibility int kcont schedule kcont t kc struct cpu info ci int nticks If the continuation is marked as INVOKING an error of EBUSY should be returned If nticks is 0 the continuation is marked as INVOKING while EXPIRED and PENDING are cleared and the continuation is scheduled to be invoked without delay Otherwise the continuation is marked as PENDING while EXPIRED status is cleared and the timer reset to nticks Once the timer expires the continuation is marked as EXPIRED and INVOKING and the PENDING status is cleared If ci is non NULL the continuation is invoked on the specified CPU if the continuations s workqueue has per cpu queues If that workqueue does not provide per cpu queues an error of ENOENT is returned Otherwise when ci is NULL the continuation is invoked on either the current CPU or the next available CPU depending on whether the continuation s workqueue has per cpu queues or not respectively void kcont destroy kcont t kc kmutex t kcont getmutex kcont t kc Returns the lock currently associated with the continuation kc void kcont setarg kcont t kc void arg Updates arg in the continuation kc If no lock is associated with the continuation then arg may be changed at any time however if the continuation is being invoked it may not pick up the change Otherwise kcont setarg must only be called when the associated lock is locked kmutex t kcont setmutex kcont t kc kmutex t lock Updates the lock associated with the continuation kc and returns the previous lock If no lock is currently associated with the continuation then calling this function with a lock other than NULL will trigger an assertion failure Otherwise kcont setmutex must be called only when the existing lock which will be replaced is locked If kcont setmutex is called as a result of the invokation of func then after kcont setmutex has been called but before func returns the replaced lock must have been released and the replacement lock if non NULL must be locked upon return void kcont setfunc kcont t kc void func void void arg Updates func and arg in the continuation kc If no lock is associated with the continuation then only arg may be changed Otherwise kcont setfunc must be called only when the associated lock is locked bool kcont stop kcont t kc The kcont stop function stops the timer associated the continuation handle kc The PENDING and EXPIRED status for the continuation handle is cleared It is safe to call kcont stop on a continuation handle that is not pending so long as it is initialized kcont stop will return a non zero value if the continuation was EXPIRED bool kcont pending kcont t kc The kcont pending function tests the PENDING status of the continuation handle kc A PENDING continuation is one who s timer has been started and has not expired Note that it is possible for a continuation s timer to have expired without being invoked if the continuation s lock could not be acquired or there are higher priority threads preventing its invokation Note that it is only safe to test PENDING status when holding the continuation s lock bool kcont expired kcont t kc Tests to see if the continuation s function has been invoked since the last kcont schedule bool kcont active kcont t kc bool kcont invoking kcont t kc Tests the INVOKING status of the handle kc This flag is set just before a continuation s function is being called Since the scheduling of the worker threads may induce delays other pending higher priority code may run before the continuation function is allowed to run This may create a race condition if this higher priority code deallocates storage containing one or more continuation structures whose continuation functions are about to be run In such cases one technique to prevent references to deallocated storage would be to test whether any continuation functions are in the INVOKING state using kcont invoking and if so to mark the data structure and defer storage deallocation until the continuation function is allowed to run For this handshake protocol to work the continuation function will have to use the kcont ack function to clear this flag bool kcont ack kcont t kc Clears the INVOKING state in the continuation handle kc This is used in situations where it is necessary to protect against the race condition described under kcont invoking kcont wq t kcont workqueue acquire pri t pri int flags Returns a workqueue that matches the specified criteria Thus if multiple requesters ask for the same criteria they are all returned the same workqueue pri specifies the priority at which the kernel thread which empties the workqueue should run If flags is 0 then the standard operation is required However the following flag s may be bitwise ORed together WQ PERCPU specifies that the workqueue should have a separate queue for each CPU thus allowing continuations to be invoked on specific CPUs int kcont workqueue release kcont wq t wq Releases an acquired workqueue On the last release the workqueue s resources are freed and the workqueue is destroyed Posted in the wee hours of Wednesday night November 10th 2011 Tags category kernel difficulty hard funded project smp networking status active Comment Lazy receive processing Contact tech kern tech net board core Funded by The NetBSD Foundation This project proposal is a subtask of smp networking and is elegible for funding independently The goal of this project is to improve the way the processing of incoming packets is handled Instead of having a set of active workqueue lwps waiting to service sockets the kernel should use the lwp that is blocked on the socket to service the workitem It is not productive being blocked and it has an interest in getting that workitem done and maybe we can directly copy that data to user s address and avoid queuing in the socket at all Posted in the wee hours of Wednesday night November 10th 2011 Tags category networking difficulty hard funded project smp networking status active Comment Separate nexthop cache from the routing table Contact tech kern tech net board core Funded by The NetBSD Foundation This project proposal is a subtask of smp networking and is elegible for funding independently The goal of this project is to remove the ARP AARP ISO SNPA and IPv6 Neighbors from the routing table Instead the ifnet structure should have a set of nexthop caches usually implemented using patricia trees one per address family Each nexthop entry should contain the datalink header needed to reach the neighbor This will remove cloneable routes from the routing table and remove the need to maintain protocol specific code in the common Ethernet FDDI PPP etc code and put it back where it belongs in the protocol itself Posted in the wee hours of Wednesday night November 10th 2011 Tags category networking difficulty hard funded project smp networking status active Comment Make TCP syncache optional Contact tech kern tech net board core Funded by The NetBSD Foundation This project proposal is a subtask of smp networking and is elegible for funding independently The goal of this project is to make the SYN cache optional For small systems this is complete overkill and should be made optional Posted in the wee hours of Wednesday night November 10th 2011 Tags category networking difficulty hard funded project smp networking status active Comment Revamped struct protosw Contact tech kern tech net board core Funded by The NetBSD Foundation This project proposal is a subtask of smp networking and is elegible for funding independently The goal of this project is to split out obvious PR xxx that should have never been dispatched through the pr usrreq pr ctloutput Note that pr ctloutput should be replaced by pr getopt pr setopt PRU CONTROL pr ioctl PRU PURGEIF pr purgeif PRC0 GETOPT pr getopt PRC0 GETOPT pr setopt It s expected that pr drain will just schedule a kernel continuation such as pr init int pr init void dsc int pr fini void dsc Posted in the wee hours of Wednesday night November 10th 2011 Tags category networking difficulty hard funded project smp networking status active Comment Virtual network stacks Contact tech kern tech net board core Funded by The NetBSD Foundation This project proposal is a subtask of smp networking and is elegible for funding independently The goal of this project is to implement full virtual network stacks A virtual network stack collects all the global data for an instance of a network stack excluding AF LOCAL This includes routing table data for multiple domains and their protocols and the mutexes needed for regulating access to it all Instead a brane is an instance of a networking stack An interface belongs to a brane as do processes This can be considered a chroot 2 for networking e g chbrane 2 Posted in the wee hours of Wednesday night November 10th 2011 Tags category networking difficulty hard funded project smp networking status active Comment 802 11 operating scheme Contact tech net Design and program a scheme for extending the operating range of 802 11 networks by using techniques like frame combining and error correcting codes to cope with low S N I ratio Implement your scheme in one or two WLAN device drivers Atheros Realtek say Posted Sunday evening November 6th 2011 Tags category networking difficulty medium project status active Comment 802 11 transmit queueing Contact tech net Modern 802 11 NICs provide two or more transmit descriptor rings one for each priority level or 802 11e access category Add to NetBSD a generic facility for placing a packet onto a different hardware transmit queue according to its classification by pf or IP Filter Demonstrate this facility on more than one 802 11 chipset Posted Sunday evening November 6th 2011 Tags category networking difficulty medium project status active Comment Convert kernel printf to aprint or log Contact tech kern Duration estimate 2 4 Weeks Most of the NetBSD kernel tree still uses printf 9 to send messages to the console primarily during boot and device configuration Each printf during device configuration should be audited and replaced with the appropriate aprint function to make the verbose boot option work properly Additionally printfs in drivers that report status or errors during normal kernel operation should be converted to use the log 9 function instead Posted Sunday evening November 6th 2011 Tags category kernel difficulty easy project status active Comment Suffix and pattern rules in BSD make Contact tech toolchain Duration estimate 2 months BSD make aka bmake uses traditional suffix rules c o instead of pattern rules like gmake s c o which are more general and flexible The suffix module should be re written to work from a general match and transform function on targets which is sufficient to implement not only traditional suffix rules and gmake pattern rules but also whatever other more general transformation rule syntax comes down the pike next Then the suffix rule syntax and pattern rule syntax can both be fed into this code Note that it is already possible to write rules where the source is computed explicitly based on the target simply by using TARGET in the right hand side of the rule Investigate whether this logic should be rewritten using the match and transform code or if the match and transform code should use the logic that makes these rules possible instead Implementing pattern rules is widely desired in order to be able to read more makefiles written for gmake even though gmake s pattern rules aren t well designed or particularly principled Posted Sunday evening November 6th 2011 Tags category userland difficulty medium project status active Comment More intelligent buffer queue management Contact tech kern Duration estimate 2 3 months NetBSD has a fixed kernel wide upper limit on transfer size called MAXPHYS which is currently set to 64k on most ports This is too small to perform well on modern IDE and SCSI hardware on the other hand some devices can t do more than 64k and in some cases are even limited to less the Xen virtual block device for example Software RAID will also cause requests to be split in multiple smaller requests There is currently work in progress to make MAXPHYS configured at runtime based on driver capability At least some of it is committed on the tls maxphys branch This project originaly suggested instead to make the buffer queue management logic which currently only sorts the queue aka disksort capable of splitting too large buffers or aggregating small contiguous buffers in order to conform to device level requirements Once the MAXPHYS changes are finalized and committed this project may be simply outdated However it may also be worthwhile to pursue this idea as well particularly the aggregation part Posted Sunday evening November 6th 2011 Tags category kernel difficulty medium project status active Comment Compressed Cache System Contact tech embed Duration estimate 2 months NetBSD version of compressed cache system for low memory devices http linuxcompressed sourceforge net Posted Sunday evening November 6th 2011 Tags category kernel difficulty medium project status active 2 comments Defragmentation for FFS Contact tech kern Heavily used file systems tend to spread the blocks all over the disk especially if free space is scarce The traditional fix for this is to use dump newfs and restore to rebuild a volume however this is not acceptable for current disk sizes The resize ffs code already contains logic for relocating blocks as it needs to be able to do that to shrink a volume it is likely that it would serve nicely as a starting point for a defragmenting tool Note that safety not scrambling the volume if the system crashes while defragging is somewhat tricky and critically important Posted Sunday evening November 6th 2011 Tags category filesystems difficulty medium project status active Comment Semantics of Contact tech kern In a file system with symlinks the file system can be seen as a graph rather than a tree The meaning of potentially becomes complicated in this environment There is a fairly substantial group of people some of them big famous names who think that the usual behavior where crossing a symlink is different from entering a subdirectory is a bug and have made various efforts from time to time to fix it One such fix can be seen in the L and P options to ksh s pwd Rob Pike implemented a neat hack for this in Plan 9 It is described in http cm bell labs com sys doc lexnames html This project is to implement that logic for NetBSD Note however that there s another fairly substantial group of people some of them also big famous names who think that all of this is a load of dingo s kidneys the existing behavior is correct and changing it would be a bug So it needs to be possible to switch the implementation on and off as per process state Posted Sunday evening November 6th 2011 Tags category filesystems difficulty medium project status active Comment Implement ext3 file system support Contact tech kern Duration estimate 2 3 months The ext2 file system is the lowest common denominator Unix like file system in the Linux world as ffs is in the BSD world NetBSD has had kernel support for ext2 for quite some time However the Linux world has moved on with ext3 and now to some extent also ext4 superseding ext2 as the baseline NetBSD has no support for ext3 the goal of this project is to implement that support Since ext3 is a backward compatible extension that adds journaling to ext2 NetBSD can mount clean ext3 volumes as ext2 volumes However NetBSD cannot mount ext3 volumes with journaling and it cannot handle recovery for crashed volumes As ext2 by itself provides no crash recovery guarantees whatsoever this journaling support is highly desirable The ext3 support should be implemented by extending the existing ext2 support which is in src sys ufs ext2fs not by rewriting the whole thing over from scratch It is possible that some of the ostensibly filesystem independent code that was added along with the ffs WAPBL journaling extensions might be also useable as part of an ext3 implementation but it also might not be The full requirements for this project include complete support for ext3 in both the kernel and the userland tools It is possible that a reduced version of this project with a clearly defined subset of these requirements could still be a viable GSOC project if this appeals to you please coordinate with a prospective mentor Be advised however that several past ext3 related GSOC projects have failed it is a harder undertaking than you might think An additional useful add on goal would be to audit the locking in the existing ext2 code the ext2 code is not tagged MPSAFE meaning it uses a biglock on multiprocessor machines but it is likely that either it is in fact already safe and just needs to be tagged or can be easily fixed Note that while this is not itself directly related to implementing ext3 auditing the existing ext2 code is a good way to become familiar with it Posted Sunday evening November 6th 2011 Tags category filesystems difficulty hard project status active 1 comment Flash translation layer Contact tech kern tech embed Implement a flash translation layer A flash translation layer does block remapping translating from visible block addresses used by a file system to physical cells on one or more flash chips This provides wear leveling which is essential for effective use of flash and also typically some amount of read caching and write buffering And it takes care of excluding cells that have gone bad This allows FFS LFS msdosfs or whatever other conventional file system to be used on raw flash chips Note that SSDs and USB flash drives and so forth contain their own FTLs FTLs involve quite a bit of voodoo and there is a lot of prior art and research do not just sit down and start coding There are also some research FTLs that we might be able to get the code for it is probably worth looking into this Note that NAND flash and NOR flash are different and need different handling and the various cell types and other variations also warrant different policy choices The degree of overprovisioning that is the ratio of the raw capacity of the flash chips to the advertised size of the resulting device should be configurable as this is a critical factor for performance Making the device recoverable rather than munching itself in system crashes or power failures is a nice extra although apparently the market considers this an optional feature for consumer devices The flash translation layer should probably be packaged a driver that attaches to one or more flash chips and provides a disk type block character device pair Posted Sunday evening November 6th 2011 Tags category filesystems difficulty medium project status active Comment IMAPfs for mail Contact tech userlevel Use puffs or refuse to write an imapfs that you can mount on var mail either by writing a new one or porting the old existing Plan 9 code that does this Note there might be existing solutions please check upfront and let us know Posted Sunday evening November 6th 2011 Tags category filesystems difficulty hard project status active Comment Coordinated caching and scheduling Contact tech kern Duration estimate 4 months and up There are many caches in the kernel Most of these have knobs and adjustments some exposed and some not for sizing and writeback rate and flush behavior and assorted other voodoo and most of the ones that aren t adjustable probably should be Currently all or nearly all of these caches operate on autopilot independent of the others which does not necessarily produce good results especially if the system is operating in a performance regime different from when the behavior was tuned by the implementors It would be nice if all these caches were instead coordinated so that they don t end up fighting with one another Integrated control of sizing for example would allow explicitly maintaining a sensible balance between different memory uses based on current conditions right now you might get that depending on whether the available voodoo happens to work adequately under the workload you have or you might not Also it is probably possible to define some simple rules about eviction like not evicting vnodes that have UVM pages still to be written out that can help avoid unnecessary thrashing and other adverse dynamic behavior And similarly it is probably possible to prefetch some caches based on activity in others It might even be possible to come up with one glorious unified cache management algorithm Also note that cache eviction and prefetching is fundamentally a form of scheduling so all of this material should also be integrated with the process scheduler to allow it to make more informed decisions This is a nontrivial undertaking Step 1 is to just find all the things in the kernel that ought to participate in a coordinated caching and scheduling scheme This should not take all that long Some examples include UVM pages file system metadata buffers VFS name cache vnode cache size of the mbuf pool Step 2 is to restructure and connect things up so that it is readily possible to get the necessary information from all the random places in the kernel that these things occupy without making a horrible mess and without trashing system performance in the process or deadlocking out the wazoo This is not going to be particularly easy or fast Step 3 is to take some simple steps like suggested above to do something useful with the coordinated information and hopefully to show via benchmarks that it has some benefit Step 4 is to look into more elaborate algorithms for unified control of everything The previous version of this project cited IBM s ARC Adaptive Replacement Cache as one thing to look at But note that ARC may be encumbered someone please check on that and update this page Another possibility is to deploy machine learning algorithms to look for and exploit patterns Note this is a serious research project Step 3 will yield a publishable minor paper step 4 will yield a publishable major paper if you manage to come up with something that works and it quite possibly contains enough material for a PhD thesis Posted Sunday evening November 6th 2011 Tags category kernel difficulty hard project status active Comment Apple ISO9660 extensions Contact tech kern Add support for Apple s extensions to ISO9660 to makefs especially the ability to label files with Type Creator IDs See http developer apple com technotes fl fl 36 html Posted Sunday evening November 6th 2011 Tags category filesystems difficulty medium project status active Comment Implement or port JFS Contact tech kern Duration estimate 1 year for port 3 years for rewrite by one developer Implement a BSD licensed JFS A GPL licensed implementation of JFS is available at http jfs sourceforge net Alternatively or additionally it might be worthwhile to do a port of the GPL code and allow it to run as a kernel module Posted Sunday evening November 6th 2011 Tags category filesystems difficulty hard project status active Comment support jails like features Contact tech kern Mentors Jean Yves Migeon Today a number of OS provide some form of kernel level virtualization that offer better isolation mechanisms that the traditional yet more portable chroot 2 Currently NetBSD lacks functionality in this field there have been multiple attempts

    Original URL path: http://wiki.netbsd.org/projects/all-flat/ (2016-02-01)
    Open archived version from archive

  • Funded projects
    approved for funding If you choose to work on any of these projects contact first the corresponding person or group and discuss the exact details of your work the schedule and the compensation you expect List of funded projects Lockless atomic FIFO LIFO queues Lockless atomic and generic Radix Patricia trees Fast protocol and port demultiplexing Implement per interface interrupt handling Kernel continuations Lazy receive processing Separate nexthop cache from

    Original URL path: http://wiki.netbsd.org/projects/funded/ (2016-02-01)
    Open archived version from archive

  • Brainstorming of project proposals
    restoring MULT to working state is an option here another possibility is to get gaols working Some fresh approach to jails might be implemented on RUMP because it basically allow us to create in process virtual machine and run them independently add shred wiping and memtest options to boot menu add ability to store entropy at shutdown time and to boot and restore same entropy at same time add a monitor chi 2 for randomness over small sample sizes to dev random investigate other ways of generating pseudo random numbers 2 mersenne twisters sampling at different speeds and throwing away random interim values due to another re keyed prng or better i e beef up our random number generation find a method to boot a boot cfg entry once and then fall back to the default method This requires especially that the boot flip back to the default method if the once off fails difficult Write new DTrace provider for watching locks lockdebug userspace or any other from available ones http wikis sun com display DTrace Providers SCTP support Change keyboard drivers to emit USB scancodes in event mode so for example ADB or Sun keyboards can coexist with things like USB keypads on the same mux and we don t need a separate InputDevice section in xorg conf for each This should be relatively easy Port FreeBSD s DAHDI implementation to NetBSD so that Asterisk on NetBSD will have hardware support FreeBSD s DAHDI implementation is SMP so this isn t a simple port Also just about every FreeBSD kernel API related to device drivers and modules are different from the NetBSD equivalent meaning that one needs to basically know both kernels Merge all PC style floppy drivers to be similar to other portable drivers that use a bus frontend with a common chip backend or possibly two pseudo DMA and real DMA Create a new HID framework so that we can merge the USB and Bluetooth HID drivers also allowing creation of drivers to properly handle devices such as Apple Magic Mouse which use several undeclared reports Improve tmpfs Update zfs pool to version 5000 Add MI interface for IEEE 802 3 Clause 45 MDIO access IEEE 802 3az Energy Efficiency Ethernet EEE support To be able to map and access PCI extended configuration space Add Support dot3 MIB Userspace Projects a Java implementation we can use across all netbsd platforms controversial a pcap based port knocking system similar to pkgsrc net knock puffs based cvsfs there s one out there which relies on extattrs fuse lowlevel Wasn t this already done ReFUSE does the upper layer of FUSE and the excellent dev fuse does the device interface but we are still lacking FUSE lowlevel functionality agc automatic setlist generation see my post to tech userlevel a few months ago for the code i used and which was used to generate all the libisns entries btw Embedded World Generator a tool to build smaller distribution and using custom

    Original URL path: http://wiki.netbsd.org/projects/ideas/ (2016-02-01)
    Open archived version from archive