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".
  • Query optimizer for find(1)
    depending on ambition Add a query optimizer to find 1 Currently find builds a query plan for its search and then executes it with little or no optimization Add an optimizer pass on the plan that makes it run faster Things to concentrate on are transforms that allow skipping I O not calling stat 2 on files that will not be matched for example or not recursing into subdirectories whose contents cannot ever match Combining successive string matches into a single match pattern might also be a win so might precompiling match patterns into an executable match form like with regcomp 3 To benefit from many of the possible optimizations it may be necessary to extend the fts 3 interface and or extend the query plan schema or the plan execution logic For example currently it doesn t appear to be possible for an fts 3 client to take advantage of file type information returned by readdir 3 to avoid an otherwise unnecessary call to stat 2 Step 1 of the project is to choose a number of candidate optimizations and for each identify the internal changes needed and the expected benefits to be gained Step 2 is to implement

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


  • Flash translation layer
    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

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

  • System-level font handling in Unix
    not the right solution figure out what the right solution is Also ascertain whether existing applications that use the fontconfig API can be supported easily directly or if some kind of possibly messy wrapper layer is needed and doing things right requires changing applications Convince the developer community that your conclusions are correct so that you can go on to step 2 1a Part of this is identifying exactly what is involved in managing and handling fonts and what applications require Implement the infrastructure If fontconfig is the right solution this entails moving it from the X sources to the base sources Also some of the functionality configurability of fontconfig is probably not needed in a canonicalized environment All of this should be disabled if possible If fontconfig is not the right solution implement something else in base Integrate the new solution in base Things in base that use fonts should use fontconfig or the replacement for fontconfig This includes console font handling groff mandoc and X11 Also the existing fonts that are currently available only to subsets of things in base should be made available to all software through fontconfig or its replacement 3a It would also be useful to kill off the old xfontsel and replace it with something that interoperates fully with the new system and also has a halfway decent user interface Deploy support in pkgsrc If the new system does not itself provide the fontconfig API provide support for that via a wrapper package Teach applications in pkgsrc that use fontconfig to recognize and use the new system This should be fairly straightforward and not require patching anything Make pkgsrc font installation interoperate with the new system This should be fairly straightforward too Take an inventory of applications that use fonts but don t use

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

  • File Systems as Network Services
    which type of file system is mounted from where e g mount t ffs dev wd0a mnt However sometimes a user is only interested in making the data available and not particularly interested in how or from where it is made available This project investigates the first steps in turning file systems into network transparent services by making it possible to mount any kernel file system type from any location on the network The file system components to be used are puffs and rump puffs is used to forward local file system requests from the kernel to userspace and rump is used to facilitate running the kernel file system in userspace as a service daemon The milestones are the following Write the necessary code to be able to forward requests from one source to another This involves most likely reworking a bit of the libpuffs option parsing code and creating an puffs client say mount puffs to be able to forward requests from one location to another The puffs protocol should be extended to include the necessary new features or another protocol defined Proof of concept code for this has already been written Currently the puffs protocol used for communication between the kernel and userland is machine dependent To facilitate forwarding the protocol to remote hosts a machine independent version must be specified To be able to handle multiple clients the file systems must be converted to daemons instead of being utilities This will also in the case of kernel file system servers include adding locking to the communication protocol The end result will look something like this start serving ffs from dev wd0a on port 12675 onehost ffs serv p 12675 dev wd0a start serving cd9660 from dev cd0a on port 12676 onehost cd9660 serv p 12675 dev cd0a

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

  • Implement file system flags to scrub data blocks before deletion
    Browse source Cross reference Release engineering Projects list Ports History Emulators Packages Browse packages Release engineering Wiki Home Edit Comment Source History New RecentChanges NetBSD Wiki projects project Implement file system flags to scrub data blocks before deletion Contact tech security Mentors Alistair G Crooks David Holland Duration estimate 3 months IMPORTANT This project was completed by Przemyslaw Sierocinski You may still contact the people above for details but please do not submit an application for this project This project requires the implementation of a new mount option and a new system and user file system flag which when set will write random data over file system blocks before they are to be deleted In the NetBSD kernel this will take place at the time of the last unlink of a file and when ftruncate is called The project will involve the investigation of retrieving or generating random data within the kernel along with research into ways of retrieving large amounts of low quality random data such as LSFR Mersenne twisters and PRNGs As well as implementing the file system flags within the kernel user level programs and library functions which manipulate the flags will need to be modified Documentation

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

  • Add kqueue support to GIO
    the past Gnome monitored the file system via a combination of FAM a system level service that provides an API to file system monitoring and GNOME VFS a high level layer that hides the interaction with FAM This approach was good in spirit client server separation but didn t work well in NetBSD FAM is abandoned Does not support kqueue out of the box FAM runs as root FAM is too hard to set up it requires rpcbind an addition to etc services a sysctl tweak and the configuration of a system level daemon To solve some of these problems a drop in replacement for FAM was started Gamin as it is known still does not fix everything Gamin is abandoned Supports kqueue out of the box but does not work very well Actually Gamin itself does not work Running the tests provided by the distfile in a modern Linux system results in several test failures Did you notice the abandoned pattern above This is important in the new world order Gnome does not use FAM any more The new structure to monitor files is the low level glib library provides the gio module which has a new file system monitoring API The GVFS module provides higher level abstractions to file system management and relies on gio for file system monitoring There is no GNOME VFS any more The problematic point is gio uses inotify directly no abstraction layers in between FAM support is still there for platforms without inotify but as it is not used in Linux any more both the FAM package and the support for it rot The goal of this project is to fix this situation There are two possible approaches The first is to extend the gio library with a new module to support kqueue

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

  • Port Hammer
    Browse source Cross reference Release engineering Projects list Ports History Emulators Packages Browse packages Release engineering Wiki Home Edit Comment Source History New RecentChanges NetBSD Wiki projects project Port Hammer Contact tech kern Duration estimate 3 6 months Port Dragonfly s Hammer file system to NetBSD Note that because Dragonfly has made substantial changes different from NetBSD s substantial changes to the 4 4BSD vfs layer this port may be

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

  • Implement per-interface 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

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