Re: removing SVR4 binary compatibilty layer
Well, I'd like to offer help keeping it (because on a personal opinion, I'd like being compatible `:-D). But the reasons are pretty reasonable and convincing :-). I have no more objections against removing it when security risks involves. -- Best wishes, MMokhi. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: removing SVR4 binary compatibilty layer
Hi, Is this removing is because no-interest on maintaining it? If it helps, I am working to use the `kern_* instead sys_*` as mentioned patch in that discussion suggests for svr4, if this helps. -- Best wishes, MMokhi. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Is there possible run a MacOS X binary
> Have you considered adding it to the FreeBSD Google Summer of Code Ideas > wiki[2]? > Maybe some brave student will like the idea and decide to spend some time on > this project. No I didn't, maybe it worth doing it :) I can do it if you suggest. I myself was brave (but officially mentor-less) while doing this :D, (I actually didn't know how i can find a mentor for this idea). I also didn't find interest among developers after call of review (for logically good sensible reasons, like why should we add it in kernel, who will maintain it, instability in first, Apple+Law issues, etc). Best wishes, Mokhi. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Is there possible run a MacOS X binary
I had started a writing a Mach-O image activator monthes ago, but time/daily-life distracted me from continuing it. Maybe some day I continue it :D Currently it's available on my github[1] if it helps. I had some success-like running of some super-simple less-than 'return A+B' programs with it :) Best regards, Mokhi. == [1] https://github.com/m0khi/FreeBSD_MachO ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WITNESS messages on 11
I'm not sure, but maybe this is related to [1]. FWIW, according to [2], LORs of witness means deadlock could be happened in that situation (if it's not a false positive), not necessarily an accurate deadlock happening IMO :) I hope it helps :) [1]http://lists.freebsd.org/pipermail/freebsd-current/2016-May/061195.html [2]https://www.freebsd.org/doc/faq/troubleshoot.html#idp63374416 Best Regards, Mokhi. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Lock order reversal errors during boot
I see this LOR often too. I thought maybe this is happening because of my Virtual Box setting :) (?!?) On 5/21/16, Will Brokenbourgh wrote: > On 05/16/16 00:44, Bjoern A. Zeeb wrote: >>> On 15 May 2016, at 07:44 , Kurt Jaeger wrote: >>> >>> Hi! >>> I am seeing 'lock order reversal' errors during boot on 11-CURRENT - r298793. A sample error: lock order reversal: 1st 0xf8011280d068 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2498 2nd 0xfe01ca539400 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:263 3rd 0xf80112a23b78 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2498 stack backtrace: #0 0x80a94bf0 at witness_debugger+0x70 #1 0x80a94ae4 at witness_checkorder+0xe54 #2 0x80a0fdd6 at __lockmgr_args+0x4d6 #3 0x80ce9626 at ffs_lock+0xa6 [...snip...] I'm not sure if this is even something I should report, but better safe than sorry, yes? >>> Yes, and there's even a page to compare your LOR against other ones: >>> >>> http://sources.zabbadoz.net/freebsd/lor.html >>> >>> Can you try if you find your LOR there ? If not, can you add it >>> to that page ? >> No he can’t and I haven’t in years either. Searching bugs might however >> be a good idea; there is a LOR category or tag somewhere. >> >> /bz > Thank you for the replies. > > I'm getting these LORs pretty frequently. Is this a normal occurrence > for 11-CURRENT or is it only me having this problem? > > Thanks > > Will Brokenbourgh > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD MachO File format, your comments on it.
Hi again. I've implemented FatElf support for Elf image activator too[1] :) Any comments/reviews on this ? I also pinged Ryan Gordon about this. Also im curious to know if any comments/reviews are done on MachO implementation[2] Best wishes and thousands of regards, Mokhi. == [1] https://github.com/m0khi/FreeBSD_FatElf [2] https://github.com/m0khi/FreeBSD_MachO ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD MachO File format, your comments on it.
errr, typo ... s/an FatELF both/and FatELF both/g :) On 3/25/16, mokhi wrote: > Adrian, thanks for your +1 :P > > So, what about EULA related things that 'David' pointed to? > If this isn't really a big problem, I have no problem to continue on > working on it, an FatELF both ;) > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD MachO File format, your comments on it.
Adrian, thanks for your +1 :P So, what about EULA related things that 'David' pointed to? If this isn't really a big problem, I have no problem to continue on working on it, an FatELF both ;) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD MachO File format, your comments on it.
So, I'll try to port FatELF as well as MachO. Choosing the better one is up to you ;) All opinions/idea are welcome and I appreciate. Best wishes, Mokhi. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD MachO File format, your comments on it.
On 3/24/16, mokhi wrote: > Then you think the better idea is porting FatELF to FreeBSD, rather > than working on MachO? > If yes, I am ready to put dedicated time on it :) [as I did for MachO] But before that, you think, is there any changes we can/should make on it? * I read something about FatELF when I was doing research for macho :) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD MachO File format, your comments on it.
Then you think the better idea is porting FatELF to FreeBSD, rather than working on MachO? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD MachO File format, your comments on it.
On 3/24/16, Achim Patzner wrote: > Would that project end in having an intelligent loader that will only map > the relevant architecture to memory (i. e. I’ll have extremely fat > executables supporting any known architecture in the universe on /usr/local > or even for all files that can be shared between machines) and keep the load > on memory and network as low as possible? It'll be one of its results, (at least) I expect :D though I'm not sure how it will have effect on network. > automatic cross-compilation to building I feel like Christmas came early. Then happy vacation ;) Thanks and thousands of regards, Mokhi. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD MachO File format, your comments on it.
Hi. I'm agreed with point you told about improvements we can do for fat format (or more). And I'm ready to do them (with your helps, sure :D). But we need short steps and more of them (a local proverb :D) IMO. If we completely do this image activator, then we can have 2 sub plans for OSX emulation and/or fat data segment redesign. I saw netbsd's way of mach-kernel/darwin emulation. They have been stopped in porting/simulating quartz (the reason described lack of developers' interest IIRC), and that relates to OSX emulating. If we wanna complete/continue that way, first we need this image activator, what's your opinion about it? BTW, in brief I believe we can have strategies to do (sub plans) and it worth (at least for me, because I'll learn good things). What's your opinion? Best wishes, Mokhi. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD MachO File format, your comments on it.
Hi guys. I'm Mahdi Mokhtari (aka Mokhi between FreeBSD friends). I am working on adding Mach-O binary format to supported formats for FreeBSD. Not for emulations on first step, but as a native supported format just like a.out [or Elf] (though it can go in both ways too). There are good reasons to have Mach-O format support IMO. It's well/clear designed file format. Can supports multiple Arch by default (It's Fat Format). Because of its Fat Format support, it can even help porting/packaging easier for projects such as Freebsd-arm or others IMO :D. At end (even not among its interesting parts, maybe :D) point, it leads and helps to have OSX emulation support on FreeBSD. BTW, i've coded[1] Mach-O support for FreeBSD with helps of FreeBSD-ppl on IRC about various aspects of this works (from fundamental points of VM-MAP, to SysEntVec for Mach-O format) and with help of Elf and a.out format codes and mach-o references. It's in Alpha state (or before it) IMO, as I'm not sure about some of its parts, but I've tested a mach-o formatted binary with it and it at least loads and maps it segments correctly :D. (it was actually a simple "return 0" C Code, compiled in a OSX, if you know how can I force my FreeBSD clang to produce mach-o files instead of ELF I'd be happy to know it, and I appreciate :D) I'd like to have your helps and comments on it, in hope to make it better and make it ready for review. Thanks and thousands of regards, Mokhi. == [1] https://github.com/m0khi/FreeBSD_MachO ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: thread-unsafety problems as spl*() ones are NOP
@imp: i exactly mean (Okay not so exact but very near ;D) what you said. after analyzing kbd.c functions (eg, kbd_realloc_array()) i concluded there are race conditions (and at result in some places there are un-protected data too) i don't mean to blindly replace splXXX() with locks, but the places i see race-conds. Also i should say there are manythings i dunno well or i dont have deep understanding of them and that's why im here to ask (ie what special condition Giant-Lock makes here [i should care about] and what is MPSAFE basically) i'd happy if you answer me those question too :D Regards, Mokhi. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: thread-unsafety problems as spl*() ones are NOP
@imp So you think I should start to put locks there and see what happens? :) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: thread-unsafety problems as spl*() ones are NOP
So in your opinion I shouldn't put mutex/spin/lock/unlock under splitty/splx? Can you please explain a bit more about MPSAFE using for me too? Regards, Mokhi. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: thread-unsafety problems as spl*() ones are NOP
i currently only wanna do patch on kbd.c (because i'm sure there is a thread-unsafety) and i don't want to add anything to spltty() nor splx(), i just wanna add things under where they've been used. isn't problem with using mutex/spin/lock/unlock etc there? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
thread-unsafety problems as spl*() ones are NOP
Hi. in kbd.c there are many places spltty()/splx() used assuming it locks/unlocks. though there is bug filed for this, and ive asked in #bsddev, Ive preferred to ask and ensure it from here again. As these functions are obsoleted now, this assumption is incorrect and some places we have thread-unsafely which leads to security problems (and/or for example double-free, etc) can i use mutex/spin/lock/unlock under where assumed a lock/unlock by using spltty()/splx() to patch it? Thanks, Mokhi. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"