Sorry I missed the meeting this morning.
I suppose in a way I was the first porter of ZOL back in the day. But a lot of the annoyances back then, "zsb" vs "zfsvfs", ZTOI / ZTOV have faded with time, either from being fixed or just touched very often. I'm much more Zen about it now. There's even #ifdef linux in the sources these days :) i try to start my Mondays by fetching ZOL, then cherry-picking in new commits, make them run, testing and merge mid week, then repeat for Windows, and merge that around Friday. Code merges goes much without thinking these days, struggling to remember specifics. * Started adding Linux to local SPL (zfs_nicenum -> zfs_nicebytes, ZTOI etc) * Hmm should totally add spl_fstrans_mark() to spl. * restore vmem_alloc -> kmem_alloc * missing taskq_wait_id() and new ZOL likes to use it instead of classic condvars. The slowest part of porting is now man-pages, and the zfs-test scripts. * ZOL still uses Makefiles in the test dirs * changing truncate->$TRUNCATE, nawk->$NAWK, dd bs=1M -> dd=1m * flexible argument order; zfs destroy tank -r -> zfs destroy -r tank * scripts just "zpool destroy -rf" at end, instead of libtest destroy_pool (we have to deal with that infernal spotlight sometimes blocking unmount) There are places I don't think we can fix. "struct uio" is opaque, so each time upstream pokes around inside I have to change; uio->uio_resid -> uio_resid(uio) uio->uio_iov[vec_idx].iov_len -> uio_getiov(uio, vec_idx, NULL, &iov_len); But that's just one of those platform differences to live with. I doubt upstream would want to add pointless wrappers. Lund -- Jorgen Lundman | <[email protected]> Unix Administrator | +81 (0)90-5578-8500 Shibuya-ku, Tokyo | Japan ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/T6a783ef79cc1cfe3-M2d9532804c60f7a4e4a9d83d Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
