DragonFlyBSD bugtracker: Issueshttps://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082023-12-05T04:09:21ZDragonFlyBSD bugtracker
Redmine DragonFlyBSD - Submit #3362 (New): Reduce package dependencies of sysutils/cdrtools in branch wit...https://bugs.dragonflybsd.org/issues/33622023-12-05T04:09:21Zmneumann
<p>Git branch withpkg.</p>
<p>Build `sysutils/cdrtools` without options DOCS, LAME and VORBIS. This should get rid of various dependent packages in `dports.base`.<br />We only need cdrtools for mkisofs, not for burning audio cds...</p> DragonFlyBSD - Submit #3355 (New): [PATCH] Port ext4 extents support from FreeBSDhttps://bugs.dragonflybsd.org/issues/33552023-08-23T03:03:33ZphcoderDragonFlyBSD - Submit #3312 (New): hammer2: redundant chain modify after chain creationhttps://bugs.dragonflybsd.org/issues/33122022-02-04T20:08:01Ztkusumikusumi.tomohiro@gmail.com
<p>It looks to me hammer2_chain_modify() calls right after hammer2_chain_create() in creat/mkdir/etc syscalls are all redundant.</p>
<p>Take a look at hammer2_xop_inode_create_det() for example. A caller process always passes NULL chain to hammer2_chain_create(), so it always allocates a new chain and then calls hammer2_chain_modify() which only initializes a new buf for devvp.</p>
<p>After successful hammer2_chain_create(), a caller explicitly calls hammer2_chain_modify() for the second time. The chain is already modified + has non-zero data_off, so it breads data for buf from above (which I believe contains garbage at this point).</p>
<p>After that a caller copies ondisk inode to its chain data which is a pointer to somewhere in devvp's buf data. The flusher eventually recursively flushes chain data to devvp along with flushing vp's buf data (user data) to devvp.</p>
<p>What I don't understand is why the second hammer2_chain_modify() is needed. The first one called from hammer2_chain_create() seems good enough in these cases.</p>
<p>In fact I've had no issue with this diff to test above.<br /><a class="external" href="https://leaf.dragonflybsd.org/~tkusumi/diff/0001-hammer2-omit-redundant-chain-modify-after-creation.patch">https://leaf.dragonflybsd.org/~tkusumi/diff/0001-hammer2-omit-redundant-chain-modify-after-creation.patch</a></p> DragonFlyBSD - Submit #3276 (New): Add option controlling whether gpt expand expands the last par...https://bugs.dragonflybsd.org/issues/32762021-05-27T04:40:52Zfalsifian
<p>Just today I needed a version of the "gpt expand" command that doesn't extend the last partition. The attached patch adds a -x option; the last partition is only expanded if -x is specified.</p>
<p>I have done minimal testing:</p>
<p>- I successfully used it without <del>x after copying my laptop's data to a larger SSD, leaving plenty of space at the end for me to install DragonflyBSD on top of the two existing OSs :</del>)</p>
<p>- I did a really quick test with the -x option on a hastily created vnode disk initialized with gpt init. I just verified that after expanding with -x, the Dfly partition got bigger.</p>
<p>I'm happy to do more testing if requested, though I'm not sure exactly what to try.</p>
<p>(This patch changes the default behaviour. I suppose it could be reversed, but a "don't expand the last partition option" seems a bit more convoluted conceptually.)</p>
<p>Patch is vs. commit 42a874b478.</p> DragonFlyBSD - Submit #3227 (New): Add HAMMER2 instructions in the installation medium READMEhttps://bugs.dragonflybsd.org/issues/32272020-03-26T22:34:50Zdaftaupepierre-alain@toret.fr
<p>As it has been discussed on irc, here's an attempt to give at least basic instructions on how to install manually using HAMMER2.</p> DragonFlyBSD - Submit #3206 (In Progress): update psm/kbd to FreeBSD 12.0 codehttps://bugs.dragonflybsd.org/issues/32062019-09-19T19:21:35Zhtseharald.brinkhof@gmail.com
<p>updates code to this FreeBSD commit</p>
<p>commit 11b574d82f92a010ea507fe962cec39e38954c3a<br />Author: philip <<a class="email" href="mailto:philip@FreeBSD.org">philip@FreeBSD.org</a>><br />Date: Sun Jun 16 03:06:05 2019 +0000</p>
<pre><code>Add macOS-like three finger drag trackpad gesture to psm(4)</code></pre>
<p>Adds three-fingered drag, natural scrolling, a bunch of bugfixes, 4-5 finger support, ...</p> DragonFlyBSD - Submit #3147 (New): Enable headless installationhttps://bugs.dragonflybsd.org/issues/31472018-10-08T10:20:30Zddegroot
<p>This patch allow installer frontend (dfuife_curses) to connect to the backend from a remote machine.</p>
<p>Patch also includes a small change to two installer makefiles, so that it can be build correctly from the /usr/src/nrelease directory (not sure if this change is formatted in a way that is acceptable).</p> DragonFlyBSD - Submit #3142 (Feedback): lib/libdmsg: Unbreak using new API EVP_CIPHER_CTX_new()https://bugs.dragonflybsd.org/issues/31422018-07-08T11:18:33Ztkusumikusumi.tomohiro@gmail.com
<p><a class="external" href="https://github.com/kusumi/DragonFlyBSD/commit/e6833c80bc898c2674e180828fe62cd0b53226e7">https://github.com/kusumi/DragonFlyBSD/commit/e6833c80bc898c2674e180828fe62cd0b53226e7</a></p>
<p>--<br />The upstream OpenSSL no longer publicly expose definition of<br />EVP_CIPHER_CTX (struct evp_cipher_ctx_st).</p>
<p>Due to this change clients need to have it as a pointer instead<br />of as a value, and allocate or free EVP_CIPHER_CTX instance by<br />EVP_CIPHER_CTX_new()/EVP_CIPHER_CTX_free().</p>
<blockquote>
<p><a class="external" href="https://github.com/openssl/openssl/issues/962#issuecomment-208792020">https://github.com/openssl/openssl/issues/962#issuecomment-208792020</a></p>
</blockquote> DragonFlyBSD - Submit #3135 (New): Add EVFILT_RECV and EVFILT_SENDhttps://bugs.dragonflybsd.org/issues/31352018-05-26T04:59:15Ztautolog
<p>This isn't complete yet, as I need to add entries in the manual, and I would like to add some more filtering code for listen sockets, and some other types of files. But I wanted to show this theory, and get feedback.</p>
<p>I spend a lot of time trying to optimize network event loops. What I end up doing is writing code that speculates on the state of the socket buffers. Level-triggering works okay for reading for some time, but if the protocol handler gets blocked, it needs to deregister or get itself into an event spin, so there ends up being a lot of de-registering and re-registering in a sophisticated platform. So then EV_ONESHOT can be used, or EV_DISPATCH with EV_ENABLE, which basically gives you edge-triggering, but then you need to register all the time. Luckily, kqueue allows you to batch these registrations, so the overhead isn't so bad, but it requires adding codepaths that aren't required in linux. So, I came up with something that I think is even better, after looking at how to add edge-triggering into kqueue.</p>
<p>kqueue has the data field that reports the socket availability in bytes. The issue with level-triggering is that the userland side only needs to be made aware of changes to that state. I realized that a more optimal interface would be for the userland to register once for each side of the connection, and then the kernel gives a single update per change to any of the socket state. Then the application can merely store the latest kevent struct on its connection struct, and always have the latest information that the kernel has on the state of the socket buffers. Then, sophisticated optimizations become straightforward. See the example echo network server in kqsbtest.c.</p> DragonFlyBSD - Submit #3041 (New): firmware: Remove embedding of multiple images in one module.https://bugs.dragonflybsd.org/issues/30412017-05-25T12:23:23ZAnonymous
<p>Hello,</p>
<p>this patch removes possibility of embedding more than one firmware image in one kernel module through the parent reference in the firmware_register() function.</p>
<p>This patch is a preparation for firmware subsystem modification for moving firmware images from kernel modules to userland.</p>
<p>The mechanism is not used and it can be functionally fully replaced by putting each firmware image in its own module.</p>
<p>Removing the functionality significantly simplifies handling of firmware images. If firmware images are moved to userland the logical grouping of modules could be expressed by putting the related firmware images into one directory if needed.</p>
<p>jan</p> DragonFlyBSD - Submit #2933 (New): Remove unix domain socket support from cat(1)https://bugs.dragonflybsd.org/issues/29332016-08-02T01:09:06Zsevanventure37@geeklan.co.uk
<p>Introduced in FreeBSD<sup><a href="#fn1">1</a></sup> and inherited in DragonFly BSD, cat(1) has the ability to utilise a unix domain socket but the usecase is somewhat limited & better served by other tools eg netcat. Attached diff removes the functionality & restores previous behaviour. This feature is exclusive to FreeBSD & DragonFly BSD and has not been adopted by the other BSDs.</p>
<p>[1] <a class="external" href="https://svnweb.freebsd.org/base/head/bin/cat/cat.c?r1=78732&r2=83482&view=patch">https://svnweb.freebsd.org/base/head/bin/cat/cat.c?r1=78732&r2=83482&view=patch</a></p> DragonFlyBSD - Submit #2921 (New): Allow moused to accept userland mouse eventshttps://bugs.dragonflybsd.org/issues/29212016-06-10T21:38:01Ztautolog
<p>Allow moused to work with sysmouse when the port is a pipe,<br /> not a real mouse device with working ioctls. Allows simple userland injection<br /> of mouse events.</p>
<p>Attached is an example that works with the Griffin PowerMate<br /><a class="external" href="https://www.amazon.com/Griffin-Technology-NA16029-Multimedia-Controller/dp/B003VWU2WA/">https://www.amazon.com/Griffin-Technology-NA16029-Multimedia-Controller/dp/B003VWU2WA/</a></p>
<p>Just run `./scrollwheel.py scroller.fifo` as a user account, and then run `moused -p scroller.fifo -t sysmouse` as root.</p>
<p>If you press down the wheel, it will multiply scrolls by 32, so you can fly through code like in the movies.</p> DragonFlyBSD - Submit #2790 (New): filedesc softrefs increment code factoringhttps://bugs.dragonflybsd.org/issues/27902015-02-21T12:00:29Zdclinkdevnexen@gmail.com
<p>Just putting locking + sifters field update in common function ...</p> DragonFlyBSD - Submit #2122 (New): [Review] Fixes to the VFS layerhttps://bugs.dragonflybsd.org/issues/21222011-08-28T17:26:29Zftigeot
<p>Hi,</p>
<p>While working on the vfs-quota branch, I found some problems in the existing<br />kernel VFS code.</p>
<p>The attached patches correspond to local commits I have created to fix them.<br />I'm not too sure if what I've done is ideal, and I'd like these patches<br />to be reviewed before pushing them to master (or not).</p>
<p>They have been applied to two of my machines (one desktop, one database<br />server), and do not seem to cause any problem.</p> DragonFlyBSD - Submit #2098 (New): [PATCH] correct ath man page example (/usr/src/share/man/man4/...https://bugs.dragonflybsd.org/issues/20982011-06-29T04:12:50Znobody
<p>152c152<br />< wepmode on wepkey 0x8736639624 weptxkey 1 up<br />---<br /> > wepmode on wepkey 0x8736639624</p>