http://blog.gmane.org/gmane.os.dragonfly-bsd.kernel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.os.dragonfly-bsd.kernel/14946 <pre>Hello everyone, My name is Daniel Flores and my proposal called “HAMMER2 compression feature” was accepted for this year’s Google Summer of Code. I already posted the draft of my proposal [1] in this kernel list, so I will not repeat much of it, but instead I want to focus on some design decisions that I’ve already made. Since I’m an inexperienced developer at this point, I’d be happy to receive your suggestions and criticism. The feature itself consists in that it attempts to compress a HAMMER2 block, which is of 64KB in size. The result should be a block of 32KB, 16KB, 8KB, etc. in size. Currently I’m searching for the algorithms that are the most appropriate for a file system. Particularly I’m searching for algorithms that are very fast; don’t require a lot of memory and processing power and offer fairly good compression rate (but not necessarily the best compression rate out of all). Right now I have two candidates – DEFLATE [2] and LZO [3]. Both of them have some available impleme</pre> Daniel Flores 2013-06-12T15:13:44 http://comments.gmane.org/gmane.os.dragonfly-bsd.kernel/14945 <pre>Hi everyone, My name is Larisa Grigore and this summer I will be developing Userland System V IPC (shared memory, semaphores and message queues). This project aims to implement System V IPC mechanism in user-space in order to achive good performance for heavy consumers. All operations as creation/destruction will be implemented through messages sent to a daemon that will take care of the management of System V IPC resources, things that were normally done in kernel. For communicating with the daemon, a process must register to it using a known named pipe. After that, both client process and daemon will use a separate channel for communication. Security is ensure with kernel help. I think that Linux implementation for SysV shared memory is a good starting point. When *shmget()*[1] is called a file is allocated assigning it some operations (in our case, *open*,* mmap* and *close* is enough). The easiest way to privide that functionality is using a driver. For shared memory, files will be created in order </pre> grigore larisa 2013-06-12T06:07:14 http://comments.gmane.org/gmane.os.dragonfly-bsd.kernel/14944 <pre>Hello! This summer I will be working on making it possible to generate a checkpoint file of a vkernel and restore it later in such way it won't be noticeable for its virtual processes. Since DragonFly already has support for checkpointing common, "normal" processes I am going to, basically, just extend its abilities to fit the vkernels' specific needs. Moreover, there already has been an attempt [1] to make vkernels checkpointable and I am going to take advantage of the work that was done. Firstly, I will complete support for checkpointing processes with multiple threads what is a feature not only vkernels will take benefit from. Then, I am going to implement restoring network interfaces (and their configuration) as well as console mode after vkernel is resumed. During the second half of the Google Summer of Code period I am going to implement support for kqueue based IO as well as MAP_VPAGETABLE and vmspaces which are essential for vkernels proper functioning. My proposal is available here [2]. You can </pre> Pawel Dziepak 2013-06-12T00:14:37 http://comments.gmane.org/gmane.os.dragonfly-bsd.kernel/14943 <pre>Hello everyone! My name is Mihai Carabas and this summer I will be working on developing harware nested page table support for vkernels.. The goal of the project is to do thepagetable walking for a guest into the harware, too. My mentor on this project will be Venkatesh Srinivas. First of all, I will have develop a mechanism for detecting the support for extended/nested page table through the "cpuid" command. In the next step, I will make a simple hardware page table walking, to see how the mechanism work. Probably it will include stub functions for VMSPACES implementation to releave the design I thought at. In the end I will be integrating the hardware page table walking into the VMSPACE API and start testing. As a final outcome, I should have a functional vkernel with hardware page table walking on one platform (the most likely Intel) and some analisys regarding the gain of perfomance obtain through this new feature. You can see my detailed proposal here [1]. Thanks, Mihai [1] http://www.google-mel</pre> Mihai Carabas 2013-06-07T09:07:49 http://comments.gmane.org/gmane.os.dragonfly-bsd.kernel/14941 <pre>hi, i'm part of GSOC this year, and i will work on an implementation of Capsicum kernel APIs for DragonFly. CAPSICUM Capsicum is a fine grained capability framework for unix systems. It can be use to sandbox applications by restricting their access to various global namespaces. While DAC and unix rights grant access at the user level, capscium is designed to implement security policies at the application or library level. Unlike MAC frameworks (SELinux, AppArmor, ...) where access profile is configured out of the code, capsicum sandboxing policy might directly be built in the application itself. Capsicum is currently implemented in the FreeBSD kernel, and some work is ongoing on the linux side. PROJECT I plan to work on 3 main subprojects : - capabilities : rights attached to file descriptors. Each operation on a filedescriptor is check against the set of rigths the filedescriptor carries. </pre> Joris GIOVANNANGELI 2013-06-06T20:08:26 http://comments.gmane.org/gmane.os.dragonfly-bsd.kernel/14940 <pre> Sascha committed adjustments to the nrelease build in master so it now uses dports. I've resurrected the daily snapshot builds and they are also now using dports. We will leave the pkgsrc support infrastructure in-place but it looks like DFly developers are now shifting to dports en-mass, so dports is what we will be actively supporting moving towards the future. It's also a whole lot easier to do bulk builds with dports, we can build the 20,000 package-set in less than a day. We are slowly creating the official infrastructure for this and ultimately expect to have a very consistent binary build running. -Matt </pre> Matthew Dillon 2013-05-30T16:25:06 http://comments.gmane.org/gmane.os.dragonfly-bsd.kernel/14936 <pre>I'm going to tag DragonFly 3.4.2 very soon, so that we have an official version with the recent fixes for DragonFly under KVM/Xen: http://lists.dragonflybsd.org/pipermail/commits/2013-May/130116.html http://lists.dragonflybsd.org/pipermail/commits/2013-May/130071.html As far as I know, there's nothing else that needs to be merged from current, but if there is - now's the time. </pre> Justin Sherrill 2013-05-28T01:21:40 http://comments.gmane.org/gmane.os.dragonfly-bsd.kernel/14935 <pre>Hi, As far as I can see, getnewvnode() always returns 0. However the path to get a new vnode, which is: objcache_get() &lt;- sysref_alloc() &lt;- allovnode() &lt;- getnewvnode() may return NULL via objcache_get. Filesystems like NFS for example use vx_put() on the vnode obtained via getnewvnode() in its nfsnode allocation path. In the case the returned vnode pointer was NULL that would cause a kernel panic. All filesystems check the return code from getnewvnode() but they don't check whether the returned vnode is NULL. In any case, I could be missing something; thoughts are appreciated. Cheers, Antonio Huete </pre> Antonio Huete Jimenez 2013-05-27T16:32:18 http://comments.gmane.org/gmane.os.dragonfly-bsd.kernel/14932 <pre>Hi, Not sure if this is the correct mailing list, correct me if not please. I've been reading the interrupt handling code in dragonfly, and I stubled across this comment on kern_intr.c:758 /* * Interrupt threads run this as their main loop. * * The handler begins execution outside a critical section and no MP lock. * * The i_running state starts at 0. When an interrupt occurs, the hardware * interrupt is disabled and sched_ithd_hard() The HW interrupt remains * disabled until all routines have run. We then call ithread_done() to * reenable the HW interrupt and deschedule us until the next interrupt. * * We are responsible for atomically checking i_running and ithread_done() * is responsible for atomically checking for platform-specific delayed * interrupts. i_running for our irq is only set in the context of our cpu, * so a critical section is a sufficient interlock. */ http://gitweb.dragonflybsd.org/dragonfly.git/blame/HEAD:/sys/kern/kern_intr.c But reading the code makes me believe it</pre> Christiano F. Haesbaert 2013-05-21T12:30:04 http://comments.gmane.org/gmane.os.dragonfly-bsd.kernel/14931 <pre>Hi, [TL;DR] As part of my Master's project I'm trying to tackle the problem of making DragonFly BSD Multiboot capable. Is this the right place to ask detailed questions regarding the approach and implementation or maybe I should contact someone specific directly? Then whom? How to adjust the file offset (not LMA/VMA) of a specific section in ELF image generated by ld? [Long version] Some facts about 32/64bit DFly and GRUB: - GRUB doesn't support switching to 64bit Long Mode (in fact it does, but not when booting Multiboot kernels). The Multiboot spec doesn't cover 64bit OSs. - DFly loader does. - Long Mode requires paging - not (or hard to be?) OS agnostic. - Patching GRUB DFly port to enter Long Mode just for DFly defeats the purpose of having a common specification/API. - `x86_64_tramp.S` is part of loader internal library `libi386`. GRUB sets up a 32bit environment and execs the kernel which must then run (almost?) the same code as the `x86_64_tramp.S` - redundancy. Given all of the above, I've d</pre> Radosław Szymczyszyn 2013-05-21T10:04:02 http://comments.gmane.org/gmane.os.dragonfly-bsd.kernel/14930 <pre>Hi, I thought this might be of interest to some people here. As of 2013-05-15 my patch enabling read support of disklabel64 has been merged to GRUB trunk. I've carried out this implementation as part of my endeavour of making DragonFly Multiboot capable. I'll post again with a few much more specific questions on this subject shortly. Regards, Radek Szymczyszyn </pre> Radosław Szymczyszyn 2013-05-21T09:01:12 http://comments.gmane.org/gmane.os.dragonfly-bsd.kernel/14929 <pre>I realized I hadn't posted an update in a while, so here's the state of things: - We've had a good number of applications; quantity is down while quality is up, compared to previous years. This is I think in part because Google is reducing the number of applications students can make, and because we have more complex tasks. - Student project selection ends the 24th. Accepted projects are announced on the 27th on the Google Summer of Code site. - We've been awarded 5 slots, and we'll be using them all. </pre> Justin Sherrill 2013-05-21T02:17:39 http://comments.gmane.org/gmane.os.dragonfly-bsd.kernel/14928 <pre>Hi, I'm trying to make sure the Silicon Image SATA chipsets can properly handle I/O requests of 256KB (their apparent theoretical limit). If you use this hardware, could you please apply the attached patch and report your findings ? Running this command as root will generate 256KB I/O requests: dd if=/dev/da0 of=/dev/null bs=1m count=10k I'm also interested if there is any issue in the course of regular operation. Thanks! </pre> Francois Tigeot 2013-05-06T10:43:52 http://comments.gmane.org/gmane.os.dragonfly-bsd.kernel/14927 <pre>Hi all , it is a known bug documented in the code too that deadlock can occur when teardown and helper thread is on the same cpu [1] Referring to bfq_teardown() in bfq.c I found a possible cause and have an amateur solution for it . it happens because when teardown sends a kill message [2] to helper thread , helper_msg_kill is called to add the kill message in queue with other messages serialized by lwkt and return to teardown function .The helper thread will only receive kill once it has executed all other messages before it . After making this call teardown destroy the message cache and the helper thread never receives the kill message which continues executing and hence a deadlock. Solution : Either we can directly kill the helper thread ( using a global variable which is usually a bad idea) without adding the message to lwkt ex if(kill==1)// where kill is global variable initialized zero and is set to 1 by teardown break; or a spinlock which makes teardown wait for the helper thread to complet</pre> tripun goel 2013-05-03T12:32:33 http://comments.gmane.org/gmane.os.dragonfly-bsd.kernel/14924 <pre>Hi Matt, Sorry if this is my second e-mail. I think i lost it in my sentmail folder. I am currently looking on BigData optimisations using DragonFly's designs. Regards, Muhammad Nuzaihan Bin Kamal Luddin </pre> Muhammad Nuzaihan Kamal Luddin 2013-05-02T07:36:55 http://comments.gmane.org/gmane.os.dragonfly-bsd.kernel/14914 <pre>I don't think there is a really good reason to remove support for 32-bit x86 machines in my opinion. As it was pointed out before, it is not like they are not capable of running DragonFly well; granted, for the project running on machines with less than 256 megabytes of RAM may not be a priority, but there are a lot of machines with &gt;= 256 MB of memory and they're 32-bit x86. I have run the latest DragonFly release on a Pentium 4 machine from 2001 with 512 MB of RDRAM, and it ran perfectly. And we're talking about a machine from 2001; newer ones are going to run it even faster. I think that the thought of thinking that a machine is not useful just because it is old is a naive and dangerous one: people do not usually test lesser known operating systems such as DragonFly on new systems. And if they do not test it, they're not going to be introduced to DragonFly, and the already small userbase will shrink even more. Another thing to remember: not everyone in the world has access to the greatest and latest mac</pre> Just a Normal Person 2013-05-01T17:50:11 http://comments.gmane.org/gmane.os.dragonfly-bsd.kernel/14910 <pre>Version 3.4 of DragonFly is officially out. The release ISO/IMG files are all available at the usual mirrors: http://www.dragonflybsd.org/mirrors/ The release notes have details on all the changes: http://www.dragonflybsd.org/release34/ If you are planning to try the new dports system for installing third-party software, check the DPorts Howto page: http://www.dragonflybsd.org/docs/howtos/HowToDPorts/ If you have an installed DragonFly 3.2 system and you are looking to upgrade, these (not directly tested) steps should work, as root: cd /usr/src git fetch origin git branch DragonFly_RELEASE_3_4 origin/DragonFly_RELEASE_3_4 git checkout DragonFly_RELEASE_3_4 ... And then go through the normal buildworld/buildkernel process found in /usr/src/UPDATING. If you are running a generic kernel, that can be as simple as make buildworld &amp;&amp; make buildkernel &amp;&amp; make installkernel &amp;&amp; make installworld &amp;&amp; make upgrade (and then reboot) If you encounter problems, please report them at bugs.dragonflybsd.org. I g</pre> Justin Sherrill 2013-04-30T04:24:14 http://comments.gmane.org/gmane.os.dragonfly-bsd.kernel/14891 <pre>Hello. My name is Daniel Flores and I’m a student from Spain. I study in Barcelona School of Informatics, which is a faculty of Polytechnic University of Catalonia, and it’s my last year before I graduate. I sent a mail with this proposal to Matthew 4 days ago, but I didn't get a reply yet, so I decided to send this to the mailing list, as it is suggested on Dragonfly's GSoC page. Before submitting any official application, I would like to ask for your opinion and criticism regarding my proposal and whether I have the required skill and adequate planning to successfully finish this project. I’m interested in implementing the block compression feature in HAMMER2, which is described on Dragonfly’s GSoC page [1]. The feature consists in that any written block should be compressed, if possible, to 50% of its size or less (in powers of 2 – 32 KB, 16 KB and so on, the initial size of block being 64 KB). It should be possible to set that compression mode on any directory, so that new contents written i</pre> Daniel Flores 2013-04-23T19:14:05 http://comments.gmane.org/gmane.os.dragonfly-bsd.kernel/14889 <pre>Hello, My name is Larisa Grigore and I am student in the second year at a master program "Internet Engineering" from Polytechnics University of Bucharest, Romania, Computer Science and Engineering Department. Currently I am working at a research project for master program. The project is about "High Availability". We try to keep a system, that runs over a microkernel from L4 family, alive no matter what happens with its components. The detected faults are segmentation faults, deadlocks and killed threads. From the point of view of recovery, two possible options are provided: restarting an address space or restoring it from some checkpoint. The user can order classic and incremental checkpoint and use those two types in correlation with fork mechanism. In order to build the HA module, memory management and fork with copy-on-write mechanisms were implemented. High Availability features, previously developed for native applications running on top of microkernel, were extended for Linux operating system. A k</pre> grigore larisa 2013-04-23T17:02:30 http://comments.gmane.org/gmane.os.dragonfly-bsd.kernel/14888 <pre>Hello. My name is Pedro. I am interested in working on DragonflyBSD as a GSoC student and the idea of making it multiboot capable is very interesting to me. I have a BSc in Computer Science and I am studying MSc in Computer Engineering at University of Malaga (Spain). I use GNU/Linux systems on a daily basis and have used FreeBSD for several years. My main contribution to free software community is the GCC backend for PIC18 target CPUs. I carried out such project as final BSc thesis. I also have been co-maintaining GNU Idutils since 2007. Apart from this, I have professional experience developing software in C language and know other languages as Perl and Bourne shell scripting language. Am I on time for discussing the work to do and preparing my application? Regards. </pre> Pedro J. Ruiz López 2013-04-22T18:48:42 http://comments.gmane.org/gmane.os.dragonfly-bsd.kernel/14886 <pre>Hello, My name is Mihai Carabas and I am a second year student at a master program from Politehnica University of Bucharest, Romania, Computer Science and Engineering Department. I was envolved last year in the GSoC program with the DragonFLY BSD scheduler ("SMT/HT awareness to DragonFlyBSD scheduler"). The ones who aren't familiar with what I had accomplished last year, here [1] is a summary with the work and results. Meanwhile Matthew did a refactoring to the scheduler and together with another improvements, the results got much better. More about me you can find on the last year proposal [2]. In the past half a year I worked on virtualizing Android on top of the L4 microkernel. The goal is to have two Androids running on a Galaxy Nexus. My role in this project was to port (virtualize) a flavour of linux kernel 3.0.8 from Samsung (tuna/maguro) on top of the microkernel. Most problems came from the fact that were three layer of addresses (physical addresses used by the microkernel, microkernel virtual ad</pre> Mihai Carabas 2013-04-21T21:42:24 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.os.dragonfly-bsd.kernel