Re: x86 bootstrap features
Emile `iMil' Heitor wrote: > Is there any news on this front? The initial multiboot2 effort for amd64 has not yet been completed. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: Proposal to remove netsmb / smbfs
sim...@netbsd.org (Simon Burge) writes: >=?UTF-8?B?SmFyb23DrXIgRG9sZcSNZWs=?= wrote: >> IIRC SMB1 is even not supported any more in current version of >> windows, so the utility of smbfs is close to 0. >I _think_ Windows 10 still supports SMB v1, however at work we >disable it by group policy becuase of security risks. Windows doesn't install SMB1 since october 2017. You can still install the component, but the latest security problems will never be fixed. SMB2 was published in 2008 and is widely in use although SMB3 exists since 2012. Samba implements SMB2 with some SMB3 features. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: x86 bootstrap features
On 20.01.2020 17:42, Emile `iMil' Heitor wrote: > > Hi Kamil, Emmanuel & all, > > On Tue, 24 Sep 2019, Kamil Rytarowski wrote: > >> On 24.09.2019 14:26, Emmanuel Dreyfus wrote: >>> On Tue, Sep 24, 2019 at 01:31:51PM +0200, Kamil Rytarowski wrote: My use-case is "qemu-system-x86_64 -kernel ./netbsd". Last I tried (with multiboot2 patches merged) it still did not work. >>> >>> I did not commit anything in multiboot support in the NetBSD kernel, >>> I only worked on bootstraps for now, hence the steady failure you >>> experience should come at no suprise. >>> >>> For now our kernel has support code for multiboot 1 for i386 only. >> >> qemu-system-i386 works, but -x86_64 not. >> >> Are there plans to add it to the amd64 kernel? > > Is there any news on this front? Being able to boot an amd64 kernel > directly > from kvm would give NetBSD the ability to be started by AWS > Firecracker[1] out > of the box which would be amazing. > > [1]: https://github.com/firecracker-microvm/firecracker > There was some work on multiboot but it was reverted. I consider qemu -kernel NetBSD/amd64 booting as a high priority. > > Emile `iMil' Heitor * > _ > | http://imil.net | ASCII ribbon campaign ( ) > | http://www.NetBSD.org | - against HTML email X > | http://gcu.info | & vCards / \ > > > !DSPAM:5e25d89018011320695049! > signature.asc Description: OpenPGP digital signature
Re: Proposal to remove netsmb / smbfs
=?UTF-8?B?SmFyb23DrXIgRG9sZcSNZWs=?= wrote: > IIRC SMB1 is even not supported any more in current version of > windows, so the utility of smbfs is close to 0. I _think_ Windows 10 still supports SMB v1, however at work we disable it by group policy becuase of security risks. Cheers, Simon.
Re: Proposal to remove netsmb / smbfs
Le lun. 20 janv. 2020 à 21:07, Jason Thorpe a écrit : > > (Cross-posted to tech-kern / tech-net because it affects networking and file > systems.) > > I would like to propose that we remove netsmb and smbfs. Two reasons: Yes, please. > 1- They only support SMB1, which is an ancient flavor of the protocol. SMB2 > was introduced in 2006 and SMB3 in 2012. SMB3 is the flavor of the protocol > favored by all of the major implementations, and for those that still support > SMB1, you sometimes have to go out of your way to enable it. > > 2- It is not MP-safe. The effort to make it MP-safe would be non-trivial. I remember netsmb particularly uses some fairly strange way how it works internally, I was meaning to look at it ever since importing it, which however never happened. IIRC SMB1 is even not supported any more in current version of windows, so the utility of smbfs is close to 0. Jaromir
Proposal to remove netsmb / smbfs
(Cross-posted to tech-kern / tech-net because it affects networking and file systems.) I would like to propose that we remove netsmb and smbfs. Two reasons: 1- They only support SMB1, which is an ancient flavor of the protocol. SMB2 was introduced in 2006 and SMB3 in 2012. SMB3 is the flavor of the protocol favored by all of the major implementations, and for those that still support SMB1, you sometimes have to go out of your way to enable it. 2- It is not MP-safe. The effort to make it MP-safe would be non-trivial. Because of (1), there is questionable utility in putting in the effort for (2). Therefore, I think it's time we retire it. For those that really need SMB client capability, there are user-space implementations available that implement newer versions of the protocol that can be hooked up via FUSE. Thoughts? -- thorpej
Re: x86 bootstrap features
Hi Kamil, Emmanuel & all, On Tue, 24 Sep 2019, Kamil Rytarowski wrote: On 24.09.2019 14:26, Emmanuel Dreyfus wrote: On Tue, Sep 24, 2019 at 01:31:51PM +0200, Kamil Rytarowski wrote: My use-case is "qemu-system-x86_64 -kernel ./netbsd". Last I tried (with multiboot2 patches merged) it still did not work. I did not commit anything in multiboot support in the NetBSD kernel, I only worked on bootstraps for now, hence the steady failure you experience should come at no suprise. For now our kernel has support code for multiboot 1 for i386 only. qemu-system-i386 works, but -x86_64 not. Are there plans to add it to the amd64 kernel? Is there any news on this front? Being able to boot an amd64 kernel directly from kvm would give NetBSD the ability to be started by AWS Firecracker[1] out of the box which would be amazing. [1]: https://github.com/firecracker-microvm/firecracker Emile `iMil' Heitor * _ | http://imil.net| ASCII ribbon campaign ( ) | http://www.NetBSD.org | - against HTML email X | http://gcu.info| & vCards / \ !DSPAM:5e25d89018011320695049!
Re: Adaptive RW locks
Hi, On Mon, Jan 20, 2020 at 02:18:15PM +0900, Takashi YAMAMOTO wrote: > > http://www.netbsd.org/~ad/2020/rwlock.diff > > > i guess in rw_downgrade > newown = (owner & RW_NODEBUG) | RW_SPIN; > > should be > newown = (owner & (RW_NODEBUG | RW_SPIN)); > > as the owner might have failed to record the lock on acquisition. Right. I'll fix it and add a comment. Good catch, thank you. Andrew
Re: libc.so's vmobjlock / v_interlock
On Sun, Jan 19, 2020 at 10:08:12PM +, Taylor R Campbell wrote: > > Date: Sun, 19 Jan 2020 21:50:24 + > > From: Andrew Doran > > > > The biggest single remaining concurency problem is the mutex on libc.so's > > uvm_object / vnode. It pops up in a number of places, but most clearly seen > > above the "uvm_fault_internal" box. > > > > I think making the vmobjlock / v_interlock a rwlock could help with making > > inroads on this problem, because in the libc.so case it's not modifying too > > much under cover of the lock (mostly pmap state). > > > > [...] > > > > Thoughts? > > I think we should try to go straight to pserialized page lookup and > skip rwlocks. Should be relatively easy to teach radixtree.c to work > pserialized. > > We probably won't want to use pserialize_perform() but can perhaps > instead use an epoch-based system with page daemon queues of dying > pages that may still be referenced under pserialize_read. This is an intriguing idea and I suspect that you've already thought about it quite a bit but I don't think we're there just yet because there's more to be dealt with first, namely that vmobjlock/v_interlock covers a lot more than the index of pages in the object. For example right now it's covering the usecounts, the flags in the vnode and the page, the PV entries in the pmap, interlocking the long term page locks (PG_BUSY), correct serialization of page visibility and TLB shootdown, and a whole lot more. I'm not fond of RW locks as a synchronisation primitive, there are usually better ways to do things, but I like the RW lock idea in this instance for two reasons. Firstly RW locks are pretty easy to understand and use so we can hopefully get a nice win for the system without it being too taxing in terms of the amount of work needed or the potential for introducing bugs. Secondly I think it would enable us incrementally attack some of the areas where we have what's really per-page state being covered by a per-object lock, which I think ties in with what you're suggesting. Andrew
Re: GSoC Proposal - Defragmentation for FFS
On 20.01.2020 04:53, Chen,Xizi wrote: > Hi NetBSD Community, > Welcome@ > I am currently a first year Master's Degree student studying Computer > Science at Northwest Missouri State University. I'm a professional C/C++ > developer with about 4 years of work experience as a storage systems > engineer. My work mostly revolved around storage stack and I/O path in > general. > > One of the issues that hits very close to home for me is file system > aging. I'm interested in learning in detail how to tackle fragmentation. > I believe "Defragmentation for FFS" project provides me an excellent > opportunity to learn more. > > I have experience using and writing software in Linux, including > experience in writing and debugging kernel modules. I am interested in > learning more about the project "Defragmentation for FFS" albeit my work > mostly involved working with XFS, I am more than willing to learn and > contribute to it. > > Looking forward to learning more about the project and working with > NetBSD community. > > Cheers, > /Xizi Chen,/ > /NWMSU/ Please elaborate your involvement in XFS. There is an ongoing (but not formally GSoC) project by Maciej to port XFS testsuite for the NetBSD filesystems. We probably could use some help here. signature.asc Description: OpenPGP digital signature
