http://permalink.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://permalink.gmane.org/gmane.os.dragonfly-bsd.kernel/14934 <pre> I see, I hadn't considered it. That answers, thanks. </pre> Christiano F. Haesbaert 2013-05-22T09:31:49 http://permalink.gmane.org/gmane.os.dragonfly-bsd.kernel/14933 <pre>On Tue, May 21, 2013 at 8:30 PM, Christiano F. Haesbaert &lt;haesbaert&lt; at &gt;haesbaert.org&gt; wrote: It means the ithread_handler() itself, instead of the interrupt handlers registered by drivers. But some of the comment in that comment block is really out-dated; I have just committed a fix. PCI legacy (line based) interrupts are shared, and they are level triggered. When the shared interrupt comes, you can't tell for sure which hardware actually generates the interrupt, so if you have two ithreads here, you will have to schedule both of them, thus you will have extra scheduling cost and it probably gives you no benefit. Best Regards, sephe </pre> Sepherosa Ziehau 2013-05-22T01:39:00 http://permalink.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://permalink.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://permalink.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://permalink.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://permalink.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://permalink.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://permalink.gmane.org/gmane.os.dragonfly-bsd.kernel/14926 <pre>... ... ... Meh. Building from source is the true unix way. Overreliance on binaries gradually devolves until you end up with a situation (like linux 'distrows') where noone knows how the system as a whole is built except for a small 'caste' of professionals who are abstracted away into some insular and poorly-documented 'developer team', and a large and ignorant user base who takes a slavish attitude to their binary servility and is behaviorally conditioned to be afraid to 'peek under the hood' and 'do' anything. That being said, binaries do have their place and should be made available. A chef, does not serve microwave pizzas, and doesn't complain about cooking from scratch - but at the same time doesn't mind going to a restaurant periodically. And we all cook meals from time to time. So too it should be, imho, with binaries. </pre> Chris Turner 2013-05-02T13:07:58 http://permalink.gmane.org/gmane.os.dragonfly-bsd.kernel/14925 <pre> I'll gladly help out/mentor the project, but currently this is a no go, as the tools are simply not (publicly) available yet. The toolchain is, but no emulator/simulator is. Linaro is working on ARMv8/AArch64 support for qemu in collaboration with ARM and Canonical, but that will still take a while. In addition to that the ARMv8 ARM (architecture reference manual) is not publicly available yet, either. In any case that's a fair bit off topic, just thought I'd throw in some facts. Cheers, Alex </pre> Alex Hornung 2013-05-02T07:35:42 http://permalink.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://permalink.gmane.org/gmane.os.dragonfly-bsd.kernel/14923 <pre> I think everyone agrees with you on this point. There is a lot of interest in having an ARM64 port. It seems like all none of the active developers have time to work on this though. I believe the DragonFly project would embrace an individual that makes a serious attempt at a port, and he/she would be supported during the process. Any volunteers? Thanks for your input! Supporting multiple architectures is the right idea, and hopefully those architectures that have a bright future. John </pre> John Marino 2013-05-02T07:17:01 http://permalink.gmane.org/gmane.os.dragonfly-bsd.kernel/14922 <pre>---------- Forwarded message ---------- From: Tobias Weingartner &lt;weingart&lt; at &gt;tepid.org&gt; Date: Wed, May 1, 2013 at 3:47 PM Subject: Re: Selection of roadmap for i386 platform End-of-Life (EOL) To: "B. Estrade" &lt;estrabd&lt; at &gt;gmail.com&gt; On Wed, May 1, 2013 at 11:55 AM, B. Estrade &lt;estrabd&lt; at &gt;gmail.com&gt; wrote: PAE does not really allow a single process to grow beyond 4GB of memory. It is really just a way to have the OS access more than 4GB of physical ram, and map the extra ram beyond 4GB into max 4GB address spaces for user processes to use. One nice thing that PAE provides (at least today) is the NX bit, which means that you can do per-page no-execute, and don't need to use segment protections to do this part. So for that reason, I'd say that dropping i386 support for i386 without PAE support might be a good idea. However, it would not solve the "limited" VM space problem, and it might end up opening other issues, since a physaddr would be 64 bits, but a vmaddr would remain at 32 bits. *shrug* YMMWV. -Toby. </pre> Tobias Weingartner 2013-05-01T22:48:19 http://permalink.gmane.org/gmane.os.dragonfly-bsd.kernel/14921 <pre>As a person who's looking for a new "home" in an open source operating system and think that that may be DragonFly, please allow me to chime in here by trying to articulate the things that I like about the project. Of course these are only my impressions and opinions. I like that it's forward thinking; a bit of fresh air in a largely stagnant landscape. I like that there seems to be a focus on innovation without sacrificing simplicity. I like that it does not show the "Me, too!" obsessions of the "Yet Another Linux" Distributions. I like that the community seems more accessible and less ego-driven than other projects. I particularly like that it seems to be more focused on the hacker rather than any particular application domain. I personally don't care for the idea of focusing on one architecture, because having more is often a forcing function to keep the code tidy and portable and avoid unnecessary hardware dependencies. But if that's the case, make it multiple actively supported and developed archite</pre> Dan Cross 2013-05-01T21:36:35 http://permalink.gmane.org/gmane.os.dragonfly-bsd.kernel/14920 <pre> It's too bad you feel this way as I honestly attempted to respond to every point you made. The whole discussion is about a long term "view" and you think looking ahead is "short-sighted". It is not clear how limiting old boxes to DragonFly 3.4 release "seriously harms" the project. Why isn't this support good enough? What assets are being risked? Why do you think this is a "market" that DragonFly should be seeking? Correct, no decision has been made. Also, FULL support for i386 will stay (none of this 2-tier support) until EOL occurs. However, I disagree with the last bit. There should be a project-wide decision on when EOL should be. Not making a decision at all would be disappointing. I don't want to see a situation where developers are marching to different drums. *THAT* is what causes harm to the project. "Premature" is in the eye of the beholder. Some think the time has already past, others will argue 2025 is too soon. It's also dismissive of all the previous arguments of why</pre> John Marino 2013-05-01T20:05:55 http://permalink.gmane.org/gmane.os.dragonfly-bsd.kernel/14919 <pre> I think it's time to clarify a few things. - No decision has been made to kill i386 - There are no people "in charge" of this kind of decision; as long as there are volonteers willing to make sure DragonFly runs on 32-bit machines and build ISO images, new i386 releases will keep coming. I can see the i386 architecture receiving less and less attention as time goes by and its number of users dwindle but there's no reason to kill it prematurely. </pre> Francois Tigeot 2013-05-01T19:27:17 http://permalink.gmane.org/gmane.os.dragonfly-bsd.kernel/14918 <pre>People are so used to BSD ports == building from source that it's going to take a while to disabuse them of the notion, I bet. The Slashdot post on the 3.4 release (for instance) had a number of people blithely going on about building from source and so on. On Wed, May 1, 2013 at 12:42 PM, John Marino &lt;dragonflybsd&lt; at &gt;marino.st&gt; wrote: </pre> Justin Sherrill 2013-05-01T19:05:34 http://permalink.gmane.org/gmane.os.dragonfly-bsd.kernel/14917 <pre>Unluckily this reply was what I expected and it doesn't really address anything in my opinion. I am sorry, though, as I quite liked DragonFly back in the day and I feel decisions as short-sighted as these seriously harm the project. Anyway, good luck to the people in charge of this project - it's too evident they really need it. Giuseppe Gatta On 5/1/13, John Marino &lt;dragonflybsd&lt; at &gt;marino.st&gt; wrote: </pre> Just a Normal Person 2013-05-01T19:01:57 http://permalink.gmane.org/gmane.os.dragonfly-bsd.kernel/14916 <pre> FWIW, FreeBSD and NetBSD support PAE (physical address extensions) which allow processes to take advantage of 32 bit hardware that can support greater than 4 GB of memory. FWIW, OpenBSD appears to not. If PAE is not part of the direction of DragonflyBSD, then it might be moot as to whether 32 bit is supported or not. You might be better of using FreeBSD, NetBSD, Linux, or even Windows. Brett &lt;snip&gt; </pre> B. Estrade 2013-05-01T18:55:31 http://permalink.gmane.org/gmane.os.dragonfly-bsd.kernel/14915 <pre>I hate responding to this negatively because you obviously put in a lot of thought and time into the message. The problem is that it's missing the point, as well as goes down the "let's save i386 path" that I tried to ward off. See below. On 5/1/2013 19:50, Just a Normal Person wrote: Machines running on less than 256M are not a priority. True. 32-bit machines can have more than 4G on them, but only 4G is accessible, which is a lot. However, the discussion isn't about memory. As I tried to point out, supporting old h/w isn't the mission of DragonFly. The issue is that supporting old h/w may hinder the advancement of DragonFly. [People can attack this premise, but supporting 1 arch takes less resources than 2] And as I have pointed out MANY times, these people can use Release 3.4. There is no reason they need the latest and greatest when their hardware is ancient. See above. In addition, I am skeptical that catering to the "ancient" crowd advances DragonFly, as in "what do they cont</pre> John Marino 2013-05-01T18:34:17 http://permalink.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 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.os.dragonfly-bsd.kernel